PLEC, A Participative Process for GUI Prototyping

PLEC, A Participative Process for GUI Prototyping Javier J. Guti´ errez1, Carlos Ar´ evalo1and David Lizcano2 1Escuela T´ ecnica Superior de Ingenier´ ıa Inform´ atica, Sevilla, Spain 2School of Computer Science, Universidad a Distancia de Madrid, UDIMA, Madrid, Spain E-mail:[email protected] Received 18 April 2019; Accepted 01 July 2019 Abstract GUI is one of the key aspect of an information system from the point of view of customers and users. This paper introduces PLEC, a participative process for designing GUI interfaces with the collaboration of the final users and stakeholders. Participants do not need technical knowledge of GUI prototype. A case study has been developed and carried out to verify if PLEC process is feasible. Keywords: GUI, prototyping, team work. 1 Introduction The Graphical User Interface also known as GUI is, in our opinion, the element of a software system more noticeable for final users. Therefore, final users are very concerned about how GUI is created. Even, a user may measure the quality of an application through its GUI. It is also a meeting point where technical and non-technical participants gather with each other. Final users do not discuss the design of the data access Journal of Web Engineering, Vol. 18 4-6, 513–538. doi: 10.13052/jwe1540-9589.18469 c 2019 River Publishers 514 J. J. Guti´ errez et al. layer or the implantation of a distributed architecture but may be critical with the GUI. This behaviour imposes a different way to work with GUI. In its development, the management of ideas, needs and the expectative of the final users are more important than other parts of the system. Unsuccessful communication is often at the root of inadequate requirements specification [1]. Usually, developers interview customers and stakeholders to discover the functionality of the system and the requirements for the GUI. After some time, customers and stakeholders could check what the developers think is the best way to implement of what they have understood from the interviews. Moreover, maybe the customer did not remember the interview or even the context of the customer has changed. This paper proposes a change of the paradigm. Instead of talking with the customers, PLEC proposes working with customers and stakeholders for developing a GUI prototype in one workshop. After that, developers and stakeholders share the same vision of the GUI system and developers may work aligned with their customers. The goal of this paper is to introduce a process, called PLEC, for obtaining a GUI prototype with the active participation of users and other nontechnical stakeholders. The goals of this process are, first, help users to think and decide which GUI they want for their systems and, second, to obtain a visual prototype that user can validate. Next paragraphs list the original contributions of this paper: 1. A LEGO c SERIOUS PLAY c (LSP from now) [2] workshop for developing a LEGOmodel describing the main goals of the GUI. 2. A translation process to create an executable prototype of the GUI designed in the LSP workshop. 3. A case study to evaluate the prototyping of GUIs using LSP and the translation process. Above contributions are called PLEC process from here. Contribution 1 (LSP workshop) allows gathering from technical and non-technical participants to build a common GUI with the support PLEC, A Participative Process for GUI Prototyping 515 of all the attendees in the workshop. GUI result is modelled using LEGOblocks. Contribution 2 (translation process) helps to translate the GUI from LEGO blocks to graphical components, then, to an executable GUI prototype for the participants of the workshop. Moreover, the authors of this paper have established a set of requirements for the PLEC process. These requirements are listed below and explained in following paragraphs: 1. PLEC process should be held in one or two sessions only. 2. PLEC process should end with an interactive GUI prototype or, at least, with enough information to create a GUI prototype the day after. 3. GUI prototype should be built using tools that allow the participation of all members in the workshops. GUI prototypes are perishable work. Their only utility is to validate ideas and provide guidelines for the implementation of the real GUI. Therefore, the time spent in prototyping must be according to the benefits of the prototype. For this reason, if PLEC takes too long, people will be neglected to assist. Consequently, we have introduced requirement 1 to create a dynamic that must be done in one day or if possible half of the day. Requirement 2 is necessary to resolve both previous problems. An interactive GUI is the final result that we are searching with PLEC process. Participants do not want any prototype, but a prototype with the ideas and the agreements of everybody in the workshop. Hence, the result must be a GUI prototype or at least it must be built the day after and the interaction must include the navigation among screens at least. The GUI prototype must be developed for people who has attended to the workshop. This is the best way to ensure the outcome of the workshop and the meaning of the LEGOmodels created. The GUI prototype could be developed by an engineer with experience in GUI tools after the workshops, but we introduce requirement 3 to encourage creating the prototype as a part of the workshop (separating the workshop in two days if necessary), involving all the participants. 516 J. J. Guti´ errez et al. Results of this paper allows to schedule a meeting with users, stakeholders, developers and other people involved in the creation of a GUI of a system under development, create a LEGOmodel with the main ideas of the prototype, translate those ideas into an interactive prototype and re-evaluate that prototype with the participants. Case study section exposes examples of the results of PLEC process. The paper is organized as follows. Section 2 exposes background works. Then, Section 3 describes the PLEC process in detail, including the LSP workshop and the teamwork techniques for defining the prototype from the results of the workshop. Afterwards, Section 4 exposes a case study applying PLEC in a real project. Finally, Section 5 exposes conclusions. 2 Background Section 2.1 exposes papers related to the application of LSP in software engineering. Then, Section 2.2 exposes papers related to GUI prototyping. 2.1 LSP in Software Engineering There are approaches for introducing gamification in requirements. For example, paper [3] presents a tool-supported collaborative requirements prioritisation process, which uses game elements to engage distributed users and stakeholders to contribute to the overall decisionmaking process. However, authors of this paper have found little evidences of the use of LEGO SERIOUSPLAYin software engineering. Authors of this paper have used the Google Scholar search engine with sets of keywords like “Lego serious play software”, “Lego serious play engineering”, “Lego serious play management” and “Lego serious play requirements”. Several results have been found but those papers are focused on creativity thinking or developing competences in a university context. Papers found that describes how to apply LSP into a software engineering context are analysed in the following paragraphs. PLEC, A Participative Process for GUI Prototyping 517 Paper [4] describes a LSP workshop for discovering requirements. This paper covers the modelling of actors, functional requirements and the relation between these two elements. The expected duration for this workshop is about 3 hours. We have facilitated some workshops for requirement (see Section 5) and 3 hours is not enough. Usually a workshop for discovering requirement takes among 4 and 6 hours for small systems and a full day for the biggest ones. The workshop from [6] is focused on asking participants what requirements they want to but we have found that this approach does not provide good results. Section 4 introduces a different LSP workshop focused on the goals of the actors and how to achieve those goals. Paper [5] describes an application of LSP for teaching software engineering in lessons of 75 minutes long. However, the process of the warm-up activity of a LSP workshop could take 40 or 50 minutes, so a 75 minutes classroom is probably not enough for developing a good LSP workshop. Previous references exposes an immature state of the art. There are little evidences of the application of LSP in software engineering. Existing works has shown a basic level of application and seems to be immature. 2.2 GUI Prototyping Paper [6] present and discuss GUI, the Graphical User Interface interaction interview, a method used to remotely discuss, develop and test GUI prototypes with users and stakeholders. LSP workshop introduced in this paper have a similar goal, however instead of discussing about a prototype, the PLEC process is focused on developing prototypes working all together. Paper [7] explores using mock end-user graphical interface construction, supplemented with textual argumentation as a means of communicating the software requirements information to software requirements analysts and providing automated assistance for requirements analysts that are examining this information. The elicitation tool has been developed and used to collect data from approximately 75 students. 518 J. J. Guti´ errez et al. Papers [8, 9] introduce one of the major web end-user software engineering (WEUSE) challenges, specifically, how to verify and validate software products built using a life cycle enacted by end-user programmers. Although their topic is out of the scope of this work, both papers introduces a comprehensive work with web components for developing tools to build web interfaces for non-expert users. Some of their ideas are applicable to PLEC due PLEC goal is that non-technical participants could build a prototype of the web GUI for a system under development. 3 PLEC Process PLEC process is composed of four steps. First step is a checkpoint to be sure that all participants share the same vision of the project. If there is not a common view, or some participants have no idea of the vision of the project, the participants have to share the vision. A simple way to set a common vision is answering the questions from Table 1. Table 1 introduces a checklist to assure the project is mature enough to perform a LEGOSERIOUS PLAYGUI workshop. Participants should answer the questions by their own, then, share the results to detect inconsistences. Answers for question in Table 1 can be short statements like the ones included in the case study at the end of this paper. After a shared vision is obtained, participants take part in a LSP workshop.As aforementioned, the goal of the LSP workshop is to build a structure of the GUI with the participation of all members in the workshop.The result of the LSPworkshop is a set of LEGObuildings, which are metaphors of the elements of the GUI. Table 1 Checklist Id Question 1 Which is the goal of the system under development? 2 Which kind of users are the main target of the system under development? 3 Which is the main functionality of the system under development? PLEC, A Participative Process for GUI Prototyping 519 People who has attended to the workshop should build the GUI prototypes, no matter their technical skill in building prototypes. This is the best way to preserve the outcome of the workshop and the meaning of the LEGOmodels created. An engineer with experience in GUI tools could build GUI prototypes after the workshops, but the participant component will get lost and the result of the prototype will not be a teamwork. Some participants could argue that their ideas from the workshop are rejected from the final prototype. This is the reason why PLEC process include additional activities for creating the GUI prototype from the results of the LSP workshop also in a participative way. Next step starts with the results of the LSP workshop. In this step, participants translate the metaphors of how the GUI should be into a GUI prototype. First, participants search for real user interfaces and they gather ideas about how to implement their metaphors into GUI components. Then, they draw GUI prototypes on paper sheets and they vote for their best ideas. Finally, all good ideas are implemented into the final GUI prototype. Figure 1 depicts an overview of the PLEC process. Next section describes the four steps from the PLEC process (Figure 1) in detail. Section 3.1 introduces LSP. Then Section 3.2 exposes the details of the LSP workshop for creating a common Figure 1 PLEC process overview. 520 J. J. Guti´ errez et al. GUI. After that, Section 3.3 introduces the activities to translate the LEGOmodels into a GUI prototype. 3.1 LSP in Software Engineering LSP is a method that enables constructive reflection and dialogue processes. Participants use LEGO bricks to create models that express their thoughts, reflections and ideas. The LSPmethod is built upon basic knowledge about how people best learn and develop. This learning process implies four steps: 1. First step should help people connect to what they are going to explore, and to understand the context and meaning of what they are about to learn more about. 2. Second step is to involve people in a process where they create a product connected to those targets of exploration, involving their own knowledge, reflections and creative skills as well on their own hands. 3. Third step should help people think about what they have created and look deeper into their own reflections and their own product, in order to become aware of what their explorations have brought to them, and to gain more insights. 4. Fourth step is that people get the chance to connect their newly obtained knowledge to new explorations they would want to pursue. LSP workshop typically takes at least one day but, at its shortest, it should last three or four hours. Furthermore, it could take even more than one day. LSP does not forces any restrictions about the time of a workshop, if there are valuable results, then the workshop may go on. However, if the time needed for a workshop is too long, people may be neglected to assist. Consequently, we have introduced requirement 1 to create a dynamic that must be done in one day only or if possible, half of the day. A LSP workshop establish a compromise among the whole participants. Participants create a solution all together using the contributions of everyone in the workshop. Furthermore, this dynamic also keep on PLEC, A Participative Process for GUI Prototyping 521 mind that no one should change the solution after the workshop ends. Results should be kept as they were built during the workshop. The meaning of the LEGOmodels stay in mind for a while. However, after some days working in other issues, that meaning goes away. Any work in LSP begins creating an individual model. This means, everybody build their own LEGOmodel. Sometimes, these models are enough to resolve the question, but some other times, additional techniques are essentials to create a global and shared solution. The only role defined in LSP is the facilitator, who have the following responsibilities: 1. She design the workshop according to the desired result. 2. She facilitates the workshop. More than one facilitator may work in the same LSP workshop. The LSP guidelines suggest a facilitator for each 10–12 participants. All workshops in the case study that will be introduced in a future section have been promoted by a certified facilitator in LSP. LSP introduces no restrictions about participants. Everyone involved with the goal of the workshop may take part. There is no need of any specific training before the workshop since some introductory exercises are performed, so everyone have the chance to learn how to participate in a LSP workshop before starting the real work. 3.2 LSP Workshop A LSP workshop is a list of questions that the participants must answer building LEGOmodels and exploring the meaning of those models. Therefore, the design of a LSP workshop is the compilation of a list of questions to dive into the knowledge. This section explains in detail the LSP workshop designs for generating a prototype of the GUI of a system under test. The scope of the workshop is the design of a GUI prototype. Other aspects of the system under development, like user roles/actors, functionality, non-functional requirements, etc. are out of the scope of the workshop. Some topics that may arise during the workshop are listed below from the practical experience of the authors of this paper. 528 J. J. Guti´ errez et al. Therefore, we have selected to recruit research members which main goal is to help to discover if the hypothesis is correct. On the occasion of understanding the result, a characterization of the participants is designed. The goal of the characterization is to discover the knowledge of the participant in GUI development and prototyping. The survey used to characterize the participants is in Table 6. Key aspects for preparing the case study are teaching participants everything they need to know to perform the practical case. One of the main goals of this project, as seen in Section 1, is to allow people from different environments to work together. There is no real need to prepare the participant before the workshop, they just come in, do the warm up activities and they are ready to start working together into the GUI building. Hence, there is no need of any special training on the participants of the case study. However, is needed to instruct the participants, as we will see in the next section. Next step is task designing where we must create the task of the case study. Due we are not working with a real team in a real project we must provide a context of a system under development, and we have to share this system with the participants so they all have the same goal and scope of the system and they can work together into GUI building. This formation is not necessary in a real context because all participants already know which system they are developing. The workshop design has been discussed in a previous section. Participants do not need to know the design of the workshop and it is a good practice that they could face the questions for first time, so the ideas are fresh and original. Next paragraphs describe the evaluation of the prototyped GUI. Two measurements are evaluated for evaluating the outcome of the case study: the prototype GUI generated and the insights of the participants of the workshop. Both measurements are evaluated using surveys. The survey for evaluating the prototype is introduced below. •The duration of the LSP workshop has been adequate •I have actively participated throughout the workshop •My opinions have been taken into consideration throughout the workshop •The questions that were proposed in the workshop were relevant to the design of the GUI of the system to be developed PLEC, A Participative Process for GUI Prototyping 529 •The answers to the questions raised have allowed me to know in detail how the GUI will be developed •I agree with the results obtained in the workshop After evaluating the measurement of the result, the criteria for determining the success of the use case may be defined. In this case, due the surveys are evaluated in a scale from 1 (strong disagree) to 7 (totally agree), the case study is success if the final result of both surveys is over 5 ina1to7scale. 4.2 Case Study Execution This section describes the implementation of the case study. Three participants, plus a facilitator, worked in this case study. The description of participants is in Table 5. Next paragraphs describe what happened during the workshop. First step was to talk about the goal of the workshop. After that, we shared our vision of the system under development, as seen in Figure 3. White blackboard from Figure 3, at the end of the room has the answer of the questions to check we all share the same vision about the system under development (questions from Table 1). Questions and answers are: •Which is the goal of the system under development? Managing biological frozen samples. •Which kind of users are the main target of the app? Embryologist •Which is the main functionality of the web? Store and search for information about the samples Then, facilitator started the LSP workshop. Participants performed the warm up activities in a previous session, therefore, the work started directly. As seen in a previous section, the first question was to design the main page of the system. The three participants designed different Table 5 Participants Name Role Leticia Domain expert Virginia Developer David Interested 530 J. J. Guti´ errez et al. Figure 3 LSP workshop during PLEC process. web pages so the final main page was a collage of the three models. After that, facilitator asked the participants to use the LEGOblocks for building additional pages that embryologist needed to reach their goals. The resulting models were connected among them using additional LEGO pieces. We iterated this question several times, until the participants exposed that the embryologist could reach their goals with the pages built. Then, facilitator asked participants to evaluate the result. Final score was 8’5 over 10 so no need to improvements were detected and the workshop was over. Figure 4 shows the results of the workshop. Post-it notes were added to provide a better description of each page. After this, we closed this session and booked the second and final session for the next week. During the second section, the case study group performed the activities described for translating a LEGOmodel into a GUI prototype. First activity was web consulting. We searched for relevant websites PLEC, A Participative Process for GUI Prototyping 531 Figure 4 Results of the LSP workshop. or those that manage information in a way could be inspiring to create our prototype. Due the system is a model for an existing app, the case study team also reviewed the whole system to capture its graphical style (Figure 5). During the web consulting, the case study performed the “web consulting” and “fragment selection” activities. Attenders took notes about web components and layouts to be used in the prototype (Figures 6(a) and 6(b)). After that, the case study team skipped the “crazy eight” activity because they though they have a clear idea of how the prototype should be. Prototype had to follow the same graphical layout that the web system so no space for crazy ideas. Therefore, the case study team developed their proposals for GUI, then, we voted for the best ideas from the proposals (Figure 6(b)). Finally, it was time to implement the ideas and the LEGO model into a prototype. Prototype was developed using Microsoft PowerPoint and capturing and editing screens from other sources, as seen in Figure 7. 532 J. J. Guti´ errez et al. Figure 5 Web consulting of relevant websites. Figure 6 (a) Notes about web components and (b) proposals on the wall. PLEC, A Participative Process for GUI Prototyping 533 Figure 7 Final prototype using MS PowerPoint. Table 6 Survey results Question Mean Median The duration of the LSP workshop has been adequate 5,5816 6 I have actively participated throughout the workshop 6,4807 6,5 My opinions have been taken into consideration throughout the workshop 5,7660 5,5 The questions that were proposed in the workshop were relevant to the design of the GUI of the system to be developed 5,2772 5,5 I agree with the results obtained in the workshop 5,5555 5,5 The answers to the questions raised have allowed me to know in detail how the GUI will be developed 4,9660 5 Prototype was created after the last session, hence the evaluation of the prototype was conducted by email. Participants received an online form with the survey. This form was introduced in a previous section. Results are introduced in Table 6. Answers are rated from 1 (totally disagree) to (7 totally agree). No generalizations could be done due to the limited results. However, participants told us in the survey that they found value applying PLEC for prototyping the new module. 534 J. J. Guti´ errez et al. 5 Conclusions This paper has described PLEC process. PLEC has three main elements: a LEGOSERIOUS PLAYworkshop for creating a conceptual GUI with the support of all participants, a set of dynamics for translating the GUI components into graphical components and the implementation of the interface in a GUI prototype. PLEC remarks the teamwork where everyone collaborates in the solution. The final GUI should have elements from all participants in a constructive way. In the case of study, we have had a person with a deep knowledge in the application and mastery of the problem, but the person who was going to develop the GUI and the rest of the system did not have that knowledge. After using PLEC, they have been able to have a shared vision and, in addition, they have developed together the interface prototype that captures the knowledge of the domain of the problem. Based on the experience of the authors implementing LSPin general and in the specific case of PLEC, we found two main problems. First one is the time needed to perform a LSP workshop. Usually a workshop consumes a whole day or at least half a day. This time is necessary to deepen the questions raised and reach consensus. All participants must be focused in the workshop for the whole duration of it. However, this time is not always available in the development of information systems. The second problem is the necessity to have a facilitator to help running the LSP workshop and the GUI creation activities. A facilitator needs knowledge and experience implementing LSP and it is not advisable that someone without experience tries to do it since it jeopardise the results of the workshop and it is possible that the participants take a bad impression of LSP. Future work is developing more case studies with different participants, organizations, projects and technologies for building GUI prototypes. For examples, we plan to apply our proposal for the design and development of technological solutions in the area of requirements engineering [14, 15], software process management [16]. Entity Identity Reconciliation based Big Data [17] and clinical process management [18]. PLEC, A Participative Process for GUI Prototyping 535 Acknowledgement This paper have been supported by the Spanish foundation HERGAR and their call “Convocatoria de Ayudas a Proyectos I+D+i 2017”. References [1] Potts, C., Takahashi, K. and Anton, A.I. (1994) Inquiry- Based Requirements Analysis, IEEE Software, Vol. 11, Issue 2, pp. 21–32. [2] Kristiansen, P., and Rasmussen, R., “Building a Better Business Using the Lego Serious Play Method: The Lego Serious Play Method”. John Wiley & Sons Inc. USA. (2014). [3] F. Kifetew, D. Munante, A. Perini, A. Susi, A. Siena, and P. Busetta, “DMGame: A Gamified Collaborative Requirements Prioritisation Tool,” Proc. – 2017 IEEE 25th Int. Requir. Eng. Conf. RE 2017, pp. 468–469, 2017. [4] Cantoni, L., Faré, M., and Frick, E., “User Requirements with Lego.”. https://d3gxp3iknbs7bs.cloudfront.net/attachments/c6a2c c2e83a9849916a88ffc6548b6736cc51250.pdf [5] Kurkovsky, S., “Teaching Software Engineering with LEGO Serious Play,” Proc. 2015 ACM Conf. Innov. Technol. Comput. Sci. Educ. – ITiCSE ’15, pp. 213–218, 2015. [6] Pettersson, J. S., and Andersson, H. (2017). Wizards of Oz in the Evolving Map of Design Research – Trying to Frame GUI Interaction Interviews Supporting Development of Interactive Systems in Interactive Sessions. HUMAN COMPUTER INTERACTION IN ISD. [7] Moore, J. M., and Texas, A. (2003). Communicating Requirements Using End-User GUI Constructions with Argumentation. 18th IEEE International Conference on Automated Software Engineering, 1527–1366. [8] Lizcano, D., Soriano, J., López, G., and Gutiérrez, J. J. (2017). Automatic verification and validation wizard in web-centred enduser software engineering. Journal of 9- Systems and Software, 125. https://doi.org/10.1016/j.jss.2016.11.025 536 J. J. Guti´ errez et al. [9] Lizcano, D., Alonso, F., Soriano, J., and López, G. (2016). Web-centred end-user component modelling. Future Generation Computer Systems, 54, 16–40. https://doi.org/10.1016/j.future. 2015.07.002 [10] Knapp J., Zeratsky J., and Kowitz B. Sprint. Transworld Editions. 2016 [11] Mohagheghi, P. (2010). An Approach for Empirical Evaluation of Model-Driven Engineering in Multiple Dimensions. From Code Centric to Model Centric: Evaluation the Effectiveness of MDD (C2M:EEMDD), (2006). https://doi.org/10.1007/s11205- 011-9933-3 [12] Ko, A. J., LaToza, T. D., and Burnett, M. M. (2013). A practical guide to controlled experiments of software engineering tools with human participants. Empirical Software Engineering, 20(1), 110–141. https://doi.org/10.1007/s10664-013-9279-3 [13] Madeyski, L., and Kawalerowicz, M. (2017). Software Engineering: Challenges and Solutions, 504, 1–13. https://doi.org/10.1007/ 978-3-319-43606-7 [14] Garc´ ıa-Garc´ ıa, J. A., Escalona, M. J., Ravel, E., Rossi, G., and Urbieta, M. (2012, December). NDT-merge: a future tool for conciliating software requirements in MDE environments. In Proceedings of the 14th International Conference on Information Integration and Web-based Applications & Services (pp. 177–186). ACM. [15] Escalona, M. J., Urbieta, M., Rossi, G., Garc´ ıa-Garc´ ıa, J. A., and Luna, E. R. (2013). Detecting Web requirements conflicts and inconsistencies under a model-based perspective. Journal of Systems and Software, 86(12), 3024–3038. [16] Garc´ ıa-Garc´ ıa, J. A., Meidan, A., Carre˜ no, A. V., and Risoto, M. M. (2017, October). A Model-Driven Proposal to Execute and Orchestrate Processes: PLM4BS. In International Conference on Software Process Improvement and Capability Determination (pp. 211–225). Springer, Cham. [17] Enr´ ıquez, J. G., Dom´ ınguez-Mayo, F. J., Escalona, M. J., Garc´ ıa- Garc´ ıa, J. A., Lee, V., and Goto, M. (2015). Entity Identity Reconciliation based Big Data Federation-A MDE approach. PLEC, A Participative Process for GUI Prototyping 537 [18] Garc´ ıa-Garc´ ıa, J. A., Escalona, M. J., Mart´ ınez-Garc´ ıa, A., Parra, C., and Wojdy´ nski, T. (2015). Clinical process management: a model-driven & tool-based proposal. Biographies Javier J. Guti´ errez received his B.S. degree in Computer Science from University of Sevilla, Spain, in 2001. Since April 2003 he has been teaching and researching in the same University. He received the Ph.D. in Languages and Computer Science in 2011. He is currently researching about testing and model driven development. His research interests include combining techniques and tools with formal methods and improving agile solutions. CarlosAr´ evalo PhD and MEng in Industrial Engineer at the University of Seville. He is a lecturer at the Department of Languages and Information Systems of the University of Seville. He has more than thirty years of experience in large software projects with private and public companies, as developer, analyst and senior consultant. He has