Free University of Bolzano/Bozen Faculty of Computer Science Bachelor in Computer Science and Engineering
Bachelor Thesis
Industrial Design Principles and Applications in Software Design – Case: Unibz Chat System
Student: Jevgenija Pantiuchina
Supervisor: Prof. Pekka Abrahamsson
Bolzano, July 2014 Abstract
The main goal of this study is to draw a parallel between software and industrial design by finding some emerging common ground among them. We presume the existence of close relationships between these two different design perspectives. The occurrence of similarities in qualitative principles, requirements and approaches demonstrates the cohesion between industrial objects and software systems. Exploratory research gathers information to illuminate such connections, patterns and links. In particular, focusing on this correlation, we have discovered the correspondence between exterior industrial design of physical objects and exterior user interface design as well as interior software system design. Since the hypothesis is the basis of our research study, it should be proved with practical appliances. For this reason, we have adapted our proposed strategy to develop chat system for the Free University of Bolzano. We have treated our chat system according to the phenomena of being an industrial object and the software at the same time by applying software principles together with industrial design principles. Before we look at practical appliances, we are providing broad and multifaceted investigation about the influence of industrial design to the software development. A practical application the industrial design principles solving real-world problems can be considered as an example of innovative process in modern computer science and engineering study. The achieved results show that supplemental application of industrial design principles during the software developing process is leading to qualitative, simple, functional and innovative final software product. This emerging theme could serve as important enhancement in the study of software development process and improvement of software quality. Consequently, we propose to proceed an aggregate study of industrial design and software principles.
2 Zusammenfassung
Das wichtigste Ziel dieser wissenschaftlichen Forschungsarbeit ist es eine Parallel zwischen Software und Industriedesign zu ziehen, indem man nach gemeinsamen Verbindungspunkten sucht. Wir sind der Meinung, dass es zwischen diesen zwei Designperspektiven eine enge Verbindung existiert. Die Vielfalt der A hnlichkeiten zwischen den Qualita tsprinzipien, Anforderungen und Methoden zeigt die Verbindung zwischen Industrieobjekten und Software. Die Information, die wir bei unserer Forschung gesammelt haben, widerspiegelt dieses Verha ltnis, Beispiele und Verbindungen. Indem wir diese Korrelation betonen, haben wir die A hnlichkeiten zwischen a ußerem Industriedesign der physischen Objekte und a ußerem Design der Benutzerschnittstelle und inneren Design des Software-Systems, gefunden. Um unsere Hypothese zu u berpru fen, haben wir eine praktische Anwendung gebraucht. Aus diesem Grund haben wir die Strategie, die wir anbieten bei der Entwicklung eines Gespra ch-Systems an der Freien Universita t Bozen, angewendet. Bei der Entwicklung eines Gespra ch-Systems haben wir die Prinzipien der Software gemeinsam mit Prinzipien des Industriedesigns angewendet und auf solchen Weise wurde dieses Gespra ch-System nicht nur als Software, aber als auch ein Industrieobjekt, angesehen. In unserer Arbeit wird eine breite und vielseitige Untersuchung u ber den Einfluss des Industriedesigns auf die Entwicklung der Software, vorgelegt. Die Ergebnisse zeigen, dass die zusa tzliche Anwendung der Prinzipien des Industriedesigns bei der Entwicklung einer Software ein qualitatives, einfaches, funktionierendes und innovatives Endprodukt von Software erschaffen hilft. Dieses Thema kann eine wichtige Entdeckung fu r wissenschaftliche Forschungen im Bereich der Entwicklungsprozesse der Software und bei der Verbesserung der Qualita t, sein. So schlagen wir vor, die Forschungen der Prinzipien des Industriedesigns und Software, weiterzufu hren.
3 Riassunto
L'obbiettivo principale di questo lavoro di ricerca e di tracciare una parallela tra il software ed il design, cercando dei punti in comune che posso emergere. Crediamo che le prospettive di questi due design sono strettamente collegate. L'emergere delle somiglianze tra i principi qualitativi, i requisiti ed i metodi mette in evidenza il rapporto tra la produzione industriale e il software. Le informazioni accumulate dalla nostra ricerca riflettono questo rapporto, gli esempi e le somiglianze. Sottolineando questa correlazione abbiamo individuato delle somiglianze tra il design esterno dei prodotti fisici industriali e il design esterno dell'interfaccia dell'utente, nonche con il design interno del sistema di software. Per verificare la nostra ipotesi ci occorreva un'applicazione pratica. Per questo motivo abbiamo applicato la strategia da noi proposta alla creazione del sistema di discussioni della Libera Universita di Bolzano. Durante il processo di creazione del sistema di discussioni abbiamo combinato i principi di software con i principi del design industriale, in tal modo il sistema delle discussioni veniva trattato non solamente come un software, ma anche come un prodotto industriale. Il nostro lavoro fornisce un ampio e multiforme studio sull'influsso del design industriale durante la creazione del software. I risultati ottenuti mostrano che l'ulteriore applicazione dei principi del design industriale nel processo della creazione del software contribuiscono alla realizzazione di un prodotto software finale di qualita , semplice, funzionale ed innovativo. Questo argomento potrebbe essere un'importante scoperta per la ricerca scientifica nel campo dei processi di creazione di software e nel miglioramento della qualita . Pertanto proponiamo di continuare insieme la ricerca nel campo del design industriale e dei principi della creazione di software.
4 Acknowledgments
I would like to express my gratitude to my supervisor, Prof. Pekka Abrahamsson, whose expertise, understanding, and patience added considerably to my university experience. I appreciate his vast knowledge and skills in many areas. Prof. Pekka Abrahamsson is the one professor and teacher who truly made a difference in my life. It was under his tutelage that I obtain design knowledge and become interested in management and software engineering. His support, effort, enthusiasm and new ideas inspired me and helped to look into usual things from new perspective. I would like to express infinite gratitude for all the knowledge he shared and time he dedicated as well as for arranging the interview with Software and Web Engineer expert, who preferred to stay anonymous. I would like to thank Prof Angelo Ventura for creating Ventura Encyclopedia, which was the main inspiration source of this study and for taking time out from his busy schedule to help me in understanding the industrial design principles. Very special thanks goes out to our technicians, especially Konrad Hofer, for helping in chat system deployment on the university virtual server. I must also acknowledge everyone who provided feedback, evaluation and comments about Unibz chat system and the whole this study.
5 Table of Contents
1. Introduction ...... 11 1.1. Motivation ...... 11 1.2. Research Questions ...... 13 1.3. Scope of Research ...... 13 1.4. Structure of Work ...... 14 2. Industrial Design ...... 16 2.1. Good Industrial Design Principles...... 16 Good Design by International Design Center Berlin (IDCB)...... 17 Principles of Good Design of Dieter Rams ...... 17 Merged Good Industrial Design Principles ...... 17 2.2. Ventura Encyclopedia ...... 21 Objects from Ventura Encyclopedia ...... 21 2.3. Bad Design ...... 23 3. Software Design ...... 25 3.1. Principles of Good Software Design ...... 25 Software Product Quality Attributes ...... 25 Process-Oriented Quality Attributes [4]: ...... 26 Software Architecture ...... 27 Source Code ...... 29 3.2. Bad Software Design ...... 33 Rotting Design ...... 33 Bad Smells in Code ...... 33 4. Link between Software and Industrial Design ...... 35 4.1. Software and Physical Objects ...... 38 4.2. User Interface Design and Industrial Design ...... 39 4.3. Model of Principles ...... 41 4.4. Related Work ...... 51 5. Unibz Chat System ...... 52 5.1. State-of-the-art Review: IRC Clients ...... 54 5.2. Industrial Design Principles in the Documentation ...... 56 5.3. Industrial Design Principles in the Source Code ...... 60 5.4. Industrial Design Principles in the User Interface ...... 64 6. Conclusions ...... 67 6.1. Answers to the Research Questions ...... 68 6.2. Future Research ...... 69 7. References ...... 70
6 Appendix ...... 72 A. User stories ...... 72 B. User Manual ...... 75
7 List of Tables
Table 1. Good Industrial Design Principles ...... 18 Table 2. Objects from Ventura Encyclopedia...... 22 Table 3. Potential Application of Industrial Design Principles in Software ...... 41 Table 4. IRC Clients ...... 54 Table 5. Application of Industrial Design Principles in Software Documentation ...... 58 Table 6. Application of Industrial Design Principles to User Interface ...... 64
8 List of Figures
Figure 1. Research Approach ...... 14 Figure 2. Ventura Encyclopedia: 300 pieces collected and exhibited in 3m2 ... 21 Figure 3. Stackable chairs by Finnish architect Alvar Aalto, 1935 ...... 22 Figure 4. Savoy Vase by Alvar Aalto, 1935 ...... 22 Figure 5. Glass boxes by Wilhelm Wagenfeld, 1938 ...... 22 Figure 6. Clock Cifra 5 by Gino Valle, 1956 ...... 22 Figure 7. Lego plastic bricks by O. K. Christiansen and G. Christiansen, 1947 . 22 Figure 8. illy coffee cup by Matteo Thun, 1992 ...... 23 Figure 9. BIC pen by La szlo Bí ro , 1943 ...... 23 Figure 10. Buttons outside the elevator...... 24 Figure 11. Buttons inside the elevator ...... 24 Figure 12. Representation of the general theory of design space ...... 35 Figure 13. Link between software features and physical entity properties ...... 36 Figure 14. Properties of Physical Entities and Software Architectural Elements ...... 37 Figure 15. Relationship between industrial and software design ...... 39 Figure 16. IPhone calculator app vs. Braun’s ET44 calculator and Braun T3 pocket radio vs. the iPod ...... 40 Figure 17. Research Model ...... 50 Figure 18. Chat System Architecture ...... 52 Figure 19. Chat System Use Case diagram ...... 57
9 List of Acronyms
DRY Don’t repeat yourself ...... 27 EUD End-User Development ...... 38 IDCB Industrial Design Center Berlin ...... 17 IRC Internet Relay Chat ...... 51 ISO International Organization for Standardization ...... 11 KISS Keep it simple, stupid ...... 26 QCW Quality Characteristic Weight ...... 64 SE Software Engineering ...... 25 SW Software ...... 23 UDB Universal Serial Bus ...... 11 UI User Interface ...... 13 UID User Interface Design ...... 13 UNIBZ Free University of Bolzano ...... 51 YAGNI You ain’t gonna need it ...... 27
10 1. Introduction
In this chapter, we will describe the motivation following the research questions, and the scope of the research. Finally, we will present the structure of the thesis.
1.1. Motivation
Nowadays it‘s difficult to make hard division line between physical and virtual worlds as well as between embodied and disembodied worlds and we must highlight that their relationship is getting more visible. The tools, such as 3D scanners and printers allow directly transform objects from digital world to physical and vice versa. The skeuomorphism in user interfaces is used – the software, where UI design is kept from its original physical objects design. Moreover, almost every device or mechanism is at least partially computerized and has some software inside. Although, software products are used in every sphere of modern world and plays significant role in our lives, there is still “a constant need to improve the way the software is being developed due to growing needs of software in everyday life and devices” [1]. Usually, it is hard to predict whether the developed software is going to be successful. Software design and development are complex undertaking and usually that involves different disciplines during all its development process. In our research, we propose the strategy, which can lead to final qualitative software product as well as simplify the software development process and its maintenance.
One of the core ideas behind our investigation project is finding convergence between industrial and software design and practical application of industrial design principles to develop university chat system. We have chosen it as a software object because of importance for all university community – chat system can improve mutual assistance among university members. Online chat system can provide immediate access to help for everyone. Moreover, while trying to resolve a problem online, users can complete other tasks, or even conduct simultaneous chats with other students or lecturers. Multilingual university students can speak various English accents and they are more likely to writing communication and quickly responding without good etiquette, especially when it comes to discuss study, research questions.
At the beginning, we will determine parallel between software and physical objects. Usually industrial products and their designs are final, static, unchanging. Accordingly, these objects usually are not able to change color, material, or shape. When the design of these products needs to be changed, simply new product is produced. In contrary, almost every software object
11 could be changed. Furthermore, the ease of introduction a change plays one of the most important roles in software quality. The effort needed to make any modifications is analyzed by software maintainability, that “according to the quality standard ISO 91261 has four components: analyzability, testability, stability and changeability”. As said Ayalew “among the maintainability sub- characteristics, changeability plays a critical role in analyzing the maintainability” [2]. It is also important to mention as Rombach pointed out, that “the maintainability of a software system is dependent on its design” [3]. From above-mentioned, we could deduce that any software must be changeable, because changeability affects software quality, which depends on software design.
Even if software and physical objects have such ponderable difference, they also have much in common. For example, the reuse of suitable parts of the code is widely applied in both software and physical objects. In software, we can call the same method of class for different objects or we copy the whole component and reuse it in other application. For comparison with an industrial object, we could take a broom with a universal handle that fits to other brushes. Hence, we reuse the same handle (as a method in SW) for different brooms (objects). Some objects such as USB jack, cables chargers etc. even have predefined standards. Herein, we see, that exist some qualitative resemblance between software and industrial engineering.
Hong Zhu in his book “Software Design Methodology” [4] points that researchers in the area of design theory and computer scientists in the context of software development have the same questions and are looking for the same answers. Moreover, author stresses the relationships between software and other designs: “In fact, software design shares many characteristics with designs in other fields” [4]. We did not find a broader study that would be looking for similarities between industrial and software design. We think that this is because Software Engineering study is much younger than Industrial Engineering: “the first digital computers appeared in the early 1940s” [5] compared to the 18th century, when people started to apply science to the industrial objects production process2. Software engineering is still in maturation step and consequently it still lacks contact points with other studies.
In our research, we are going to examine gradually actual questions according to the main goal. At the beginning, to define a uniform model of industrial and software principles, after we are analyzing the similarities and differences between industrial and software products. Then we are going to apply good software design principles together with good industrial design principles, rules and other useful discovered information to our university chat system development. Finally, by evaluating external and internal parts of our developed software – Unibz chat system – we will be able to answer research questions of this study.
1 http://en.wikipedia.org/wiki/ISO/IEC_9126 2 http://en.wikipedia.org/wiki/Industrial_engineering
12 1.2. Research Questions
In this study, the main research question is: 1. How the industrial design principles can be useful for software design and development? Additionally to the main research question, we will provide the answers to the supporting research questions: 1. What are the differences and the similarities in industrial design and SW design principles? 2. What are the industrial design role, impact and importance to software quality? 3. How can we apply industrial design principles in software? 4. What is the relationship between the exterior industrial design of physical objects and exterior user interface design and interior software system design?
1.3. Scope of Research
Our study consists of two main parts: the establishment of a new model with software and industrial design principles and the practical application of these principles for the chat system design. In this study, we are not applying industrial design principles to software process management. As well, we are not comparing final products quality attributes of industrial design with quality attributes of software project. We are focusing only on external user interface design, internal software architecture design and code design. Internal software design is invisible for the users of the system, but visible to the current and future systems developers and designers.
13 Search for similar touching areas in software and industrial design, where principles can be shared T h Software Design Industrial Design
Exterior: Visible Exterior: e User Interface relationship Industrial Object o Interior SW System Design Interior: is exterior from r SoftwareDesign developers’ point of view e t Research of good Software design Research of good Industrial design i principles (of found areas) principles (of found areas) c a Find similarities and differences in principles
l Research methods for industrial design principles application in Software design P Model r
a Requirements collection c Architecture Design
t Testing i Implementation
c UNIBZ Chat System a l Conclusions Figure 1. Research Approach
1.4. Structure of Work
In this sub-chapter, we are explaining the structure of this work. We have already described the motivation, research questions, and the scope of the research following the research approach of our study. This work has seven chapters: Introduction, Industrial Design, Software Design, Link between Software and Industrial Design, Unibz Chat System, Evaluation and Conclusions. Chapter 2 gives an overview about good industrial objects design according to the famous designers, such as J. de Noblet, B. Munari, and D. Rams etc. We have collected their formulations about good design and finally assembled them as a set of 20 good industrial design principles. These 20 principles are the background of our study.
14 Chapter 3 reviews Software design objectives, principles and rules according to the well-known software engineers, such as B. Witt, T. Baker, W. Merritt, D. Parnas, D. M. Weiss, R. C. Martin and D. Wampler, A.D. Hunt, and Microsoft Team. At the end of this chapter, we are reviewing principles of a bad software design according to R.C. Martin, Kent Beck and Martin Fowler. Chapter 4 describes general theory of design space and provides the relationship of this theory with software design theory by determining the link between software features and physical entity properties. Afterwards skeuomorphism sketched in Apple’s previous user interfaces inspired by Braun. Lastly, the model of the application of industrial principles to software is depicted, following the explanatory table. Chapter 5 describes chat system implementation process applying industrial design principles. Chapter 6 contains the conclusions of our study. In this chapter, we are providing answers to the stated research questions and possible future research. The work is finished by providing References and Appendix to our study.
15 2. Industrial Design
Il design – diversamente dall’arte – necessita di motivazioni pratiche e trova le proprie motivazioni soprattutto in quattro presupposti: essere diretto alla società, essere funzionale, significativo e concreto. Michael Erlhoff, 1987 [6] This chapter gives a short general definition of industrial design and constitutes good industrial design principles. Firstly, we are going to give the definition what is an industrial design according to French author J. de Noblet. Then we are going to present an opinion of the famous Italian designer when he considers the industrial products acceptable. We are going to give the answer to the question – “What is a good design?” according to German literature from International Design Center Berlin. Additionally, we are presenting 10 principles of good industrial design formulated by Dieter Rams3, who was the chief industrial designer of Braun for 40 years. Finally, we are going to concatenate all the mentioned points and invent our model of good industrial design principles. For conclusion to this chapter, we are going to present Ventura Encyclopedia and some examples from it.
2.1. Good Industrial Design Principles
Different useful, habitual objects surround us all. The most of these objects are successfully and widely used and this is already enough to consider them good industrially designed products. During the creation process, designers maximally fulfill the requirements for a good industrial product. We were not able to find one concrete and precise formulation of these requirements, therefore we research the definitions of the most popular designers about good design, and using collected information, we try to invent our principles of a good design. One of the possible answers to the question “what is a good industrial product” could be found from the definition of industrial design given by Jocelyn de Noblet: “Industrial Design is the use of both applied art and applied science to improve the aesthetics, ergonomics, functionality, and/or usability of a product [...]The role of an industrial designer is to create and execute design
3http://en.wikipedia.org/wiki/Dieter_Rams
16 solutions for problems of form, usability, physical ergonomics, marketing, brand development, and sales.” [7]. Summarizing Noblet’s words cited above, a good industrial product is aesthetic, ergonomic, functional and usable. According to one of the most popular Italian designer Bruno Munari, the industrial product is acceptable, if it possesses these requisites: it is functional, low-cost and ergonomic. That is an optimal relationship between the shape of the object and its use by humans [8].
Good Design by International Design Center Berlin (IDCB) The other description of good design was given by International Design Center Berlin4 (non-profit German institution) in 1979, during their exhibition. According to IDCB, good design: 1. Has appropriate shape 2. Is functional and attractive 3. Is evolutional 4. Is environmentally friendly, reusable and ergonomic 5. Is safe
Principles of Good Design of Dieter Rams Dieter Rams gave quite precise and complete answer to the question above. In 1970ths, he asked himself whether his design is good design. His formulated answer became ten principles of good industrial design: According to Dieter Rams, good design: 1. Is innovative 2. Makes a product useful 3. Is aesthetic 4. Makes a product understandable 5. Is unobtrusive 6. Is honest 7. Is long lasting 8. Is thorough down to the last detail 9. Is environmentally friendly 10. Is as little design as possible
Merged Good Industrial Design Principles The following table presents and explains the most important and valuable principles of a good industrial design, according to our point of view. In order http://www.idz.de/
17 to define short and simple principles, we have taken a union of Noblet’s, Munari’s, Ram’s and IDCB’s principles, extracted the most important ones, simplified (renamed) them and ordered them by alphabetical order.
Table 1. Good Industrial Design Principles
# Principle Explanation Authors Citation # (good industrial design must be) 1 Accurate is thorough down D. Rams 14 to the last detail 2 Adequate price has affordable J. Noblet 5 price, low-cost B. Munari 2 3 Aesthetic is well executed, J. Noblet 1 beautiful D. Rams 9 B. Munari 20
4 Appropriate has comfortable J. Noblet 5 shape and suitable shape B. Munari 2 IDCB 7, 17 5 Attractive has good visible IDCB 3 presentation 6 Branded has its own mark J. Noblet 5 7 Environmentally considers IDCB 6 friendly environment protection, energy D. Rams 19 conservation and re-use 8 Ergonomic is efficient and J. Noblet 1, 5 comfort B. Munari 2 IDCB 6 9 Evolutional uses the latest IDCB 16 technology 10 Functional does what it must J. Noblet 1 to do B. Munari 2 IDCB 3 M. Erlhoff 4 11 Honest is what is really is D. Rams 12
12 Innovative was not yet D. Rams 15 created before, new 13 Long lasting never becomes D. Rams 13 antiquated, not fashionable 14 Market is easy to J. Noblet 5 placement introduce in the B. Munari 21 market Optimal shape B. Munari 2
18 # Principle Explanation Authors Citation # (good industrial design must be) 15 consists of must to IDCB 7, 17 be parts D. Rams 18 16 Safe has no danger for IDCB 17 health 17 Simple / Pure concentrates on D. Rams 18 essential aspects, M. Erlhoff 4 has as little design as possible 18 Understandable is self-explanatory, D. Rams 10 intuitive and concrete M. Erlhoff 4 19 Unobtrusive clearly fulfills a D. Rams 11 purpose 20 Usable/ useful satisfies the needs J. Noblet 1, 5 and usefulness IDCB 7 criteria’s D. Rams 8
Citations from Table 1 and their translations Every citation number from Table 1 corresponds to the citation sequence number from the list. The list of citations shows different designers points of view about principles of good industrial design, object, product etc. Some citations are in Italian and therefore we provide the translations into English. 1. “Industrial Design is the use of both applied art and applied science to improve the aesthetics, ergonomics, functionality, and/or usability of a product”, J. Noblet [7] 2. “Perche un prodotto sia considerato soddisfacente, deve possedere requisiti di funzionalita , di economicita , di ergonomia (cioe un rapporto ottimale tra la forma dell’oggetto e la sua utilizzazione da parte dell’uomo” (“the product is acceptable, if it possesses these requisites: it is functional, low-cost and ergonomic. That is an optimal relationship between the shape of the object and its use by”), B. Munari [8] 3. “Deve rendere visibile la funzione del prodotto, il modo di maneggiarlo e in questo senso deve renderlo leggibile per l'utente” (“it should make visible the functions of the product, the way to handle it, and be attractive for the user at the same time”), IDCB [9] 4. “Il design […] essere funzionale, significativo e concreto” (“the design must be functional, significant and concrete”), M. Erlhoff [6] 5. “The role of an industrial designer is to create and execute design solutions for problems of form, usability, physical ergonomics, marketing, brand development, and sales.”, J. Noblet [7]
19 6. “Non si deve restringere solo al prodotto in sé e per sé man deve considerare anche i problemi della tutela dell’ambiente, del risparmio energetico, del riutilizzo, del suo uso prolungato e dell’ergonomia (“it cannot be restricted only to the product itself, but should also consider such problems as environment protection, energy conservation, re- use, prolonged use and ergonomics”), IDCB [9] 7. “Il buon design non può essere una tecnica dell'involucro deve portare a esprimere la specificità del singolo prodotto con una corrispondente progettazione della forma” (“good design is not a technique to wrap an item, it should express the specificity of a single product with an appropriate shape design”), IDCB [9] 8. 2nd principle: “Good design makes a product useful”, D. Rams [10] 9. 3rd principle: “good design is aesthetic”, D. Rams [10] 10. 4th principle: “good design makes a product understandable”, D. Rams [10] 11. 5th principle: “good design is unobtrusive”, D. Rams [10] 12. 6th principle “good design is honest”, D. Rams [10] 13. 7th principle: “good design is long lasting”, D. Rams [10] 14. 8th principle: “good design is thorough, down to the last detail”, D. Rams [10] 15. First principle: “good design is innovative”, D. Rams [10] 16. “Il buon design deve far diventare trasparente il livello ultimo dell'evoluzione tecnica” (“good design should be transparent on the ultimate level of technical evolution”), IDCB [9] 17. “Il buon design deve assumere come punto di partenza della progettazione dalla forma il rapporto tra l'uomo e l'oggetto, tenendo in particolare considerazione la medicina del lavoro e la sicurezza” (“good design should make as a starting point the importance of the relationship between man and object, especially the object specifically, taking into account the occupational medicine and safety”), IDCB [9] 18. 10th principle: “good design is as little design as possible”, D. Rams [10] 19. 9th principle: “good design is environmentally friendly”, D. Rams [10] 20. “Oggetto di design [...] deve [...] possedere alcuni requisiti estetici” (“design object must possess some aesthetic requirements”), B. Munari [8] 21. “Un prodotto […] competitivo sul mercato rispetto ad altri prodotti analoghi” (“a product should be competitive in the market compared to other similar products”), B. Munari [8] As we can see from the table about good industrial design principles, designers usually do not distinguish principles and quality attributes. Analyzing their formulations and answers about good design, we can see that they put the methods (principles) and the goals (quality attributes) to the same list. Unlike of Software Engineering, where these two concepts usually are separated. There are huge amount of studies about principles and methodologies of software development process, for example: Waterfall,
20 Prototype, Incremental, Iterative, V-Model, Spiral, Scrum, Agile etc. All these methodologies present different techniques to develop qualitative Software. Although, these methodologies are outside the scope of our study.
2.2. Ventura Encyclopedia
Ventura Encyclopedia [11] is the encyclopedia of live product, created by designer, architect and Professor Angelo Ventura. It is not a usual encyclopedia, because all objects are collected and put in three-square meters. Every object on the shelf has a reference to description from the design book. The author has created a new, modern, innovative and unconventional way to get knowledge about objects. It allows not only reading about good industrial objects, but also be acquainted with them, touch and experience them.
Figure 2. Ventura Encyclopedia: 300 pieces collected and exhibited in 3m2 Ventura Encyclopedia is located on the third floor of the Faculty of Computer Science, piazza Domenicani 3, Bolzano, Italy.
Objects from Ventura Encyclopedia We have selected some objects from Ventura Encyclopedia, which, according to us, could be useful to our software. We can claim that all these objects are good industrial products. They are popular and widely used. Every product satisfies almost all principles of good design.
21 Table 2. Objects from Ventura Encyclopedia
Picture Reference Description Figure 3. Stackable These chairs [12] are chairs by Finnish made from wood, architect Alvar Aalto, comfortable to sit, occupy 1935 a little space when stacked together, cheap in production, and suit almost every room because of the design simplicity
Figure 4. Savoy Vase Savoy vases have a unique, by Alvar Aalto, 1935 asymmetric shape. Every vase height is selected according to its functionality. For example, big vases are for flowers, small for office supplies. Figure 5. Glass boxes These transparent boxes by Wilhelm are stackable and Wagenfeld, 1938 multifunctional. They are made from thick glass, which makes them durable and attractive
Figure 6. Clock Cifra 5 This clock has a big screen by Gino Valle, 1956 with enough big digits. The size successfully fulfill clocks functionality. This clock model was produced in different colors to give more flexibility for users. Controls are hidden behind Figure 7. Lego plastic Lego is very popular and bricks by O. K. interesting constructor Christiansen and G. game for children, which Christiansen, 1947 contributes to the development of children’s’ thinking
22 Picture Reference Description Figure 8. illy coffee This white coffee cup “illy” cup by Matteo Thun, can be still found today in 1992 many bars. It consists only from 2 colors (white and red), standard coffee cup size and shape with comfortable handle. It is ergonomic and handsome. Everything, what a coffee cup needs to have
Figure 9. BIC pen by This pen was a La szlo Bí ro , 1943 revolutionary product which simplified the life of millions people. This small pen has a complex system inside, which makes the writing easy and fast. The pen is so cheap, that is available to everyone
2.3. Bad Design
We are surrounded by not only well-designed objects, but also often misleading and hardly understandable design objects. Moreover, often these objects perform the function that we need at this period. Therefore, we are forced to use them. These objects are everywhere, for example uncomfortable chairs in the canteens or university rooms, heavy doors with small handles, small information stands in bus stops, unclear elevator buttons etc. We would like to show one of the unclear and misleading design examples – the elevator buttons at Bolzano-Bozen train station.
23 Not a button
Button
Button Button
Figure 10. Buttons outside the elevator Figure 11. Buttons inside the elevator
Buttons with numbers inside and outside elevator are completely the same. Although, in order to call the elevator from outside, you should press the pink button instead of the button with number. However, when you are inside – you must press the button with a floor number. We have watched the people entering elevator about one hour. The elevator was used in total eighteen times. Eleven times people tried to press the button with a floor number, which is not possible to press. Only after observing it, they pressed the pink button. Three people few times tried to press stronger the wrong button. Almost all of these eleven people seemed to be tourists. Other seven people, who pressed immediately the pink button, seemed as locals, who have already known this pink button. Therefore, we can deduce that everyone who was using this elevator for the first time tried to press the wrong button. The use of the same buttons in the same elevator when ones can be pressed and others no – is a sign of ambiguous, unclear and misleading design. We can claim that such design is considered bad. Hence, it would be better to change it.
24 3. Software Design
In this chapter, we are presenting lists of good software design principles according to the design objectives by Witt, Baker and Merritt [13], requirements of good designs by Parnas and Weiss [14], common process- oriented quality attributes of software design and other discovered principles and rules. Afterwards, we will compose a list of rotting design principles according R.C. Martin [15] and a list of bad code smells according K. Beck and M. Fowler [16]. We have come to this solution because after revising pile of resources we have not found only one complete set of good and bad software design principles. As has said H. Zhu “in the literature of software design methodology, different authors have proposed different sets of quality attributes that are considered as most desirable” [4]. Subsequently the author has made one numbered list of quality attributes from different sources. In our study, we will follow H. Zhu strategy and make our list of good software design principles.
3.1. Principles of Good Software Design
In 1972 one of the formal definitions of Software Engineering was given in “Information Processing” journal, where software engineering was defined as “the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines" [17]. In the more than 40 years, SE significantly has evolved. To develop qualitative software – new methods, techniques, methodologies, principles, rules etc. have been introduced. All these methods always seek the same goal – the final product fulfills all the requirements and quality attributes. They were defined in ISO/IEC 91265 model and is the international standard for software quality evaluation, issued in 1991. In 2001 was issued a revision in four pats of ISO/IEC 9126-1 to 9126-4 and in 2011 was issued an extended ISO/IEC 250106 model, which has eight product quality characteristics.
Software Product Quality Attributes Quality attributes are resulting properties and goals for developed software product and its model. According Microsoft, “the extent to which the
5 http://en.wikipedia.org/wiki/ISO/IEC_9126 6http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumb er=35733
25 application possesses a desired combination of quality attributes […] indicates the success of the design and the overall quality of the software application” [18]. Although, different authors consider different quality attributes the most essential. The following list presents principles and rules for product-oriented quality attributes of SW design by Witt, Baker and Merritt’s and Parnas and Weiss’s. Witt, Baker and Merritt’s have pointed such design objectives [13]: 1. Modular – high cohesion, low coupling [19] 2. Portable – independence from environment 3. Malleable – flexibility, modifiability 4. Conceptual integrity – adhering to one single concept, predictability, understandability 5. Intellectual control – understanding concept by their responsible persons Parnas and Weiss’s requirements and quality attributes of good software designs [14]: 6. Consistent – is well structured, organized, appropriate information hiding 7. Simple – ‘as simple as possible, but no simpler’(Albert Einstein) 8. Efficient – use of resources 9. Adequate – meets stated requirements 10. Flexible – easy to make changes 11. Practical – modules provides only required facilities, not more or less 12. Implementable – has theoretically computable and achievable functions with available SW and HW 13. Standardized – is standardized documented, well-defined, has familiar notation From the list of software quality attributes and from our Table 1. Good Industrial Design Principle we can see that appears the first set of correspondence between industrial design principles and SW design quality attributes, such as understandability, simplicity and practicability. Despite of occurrence of these coincidences, the qualitative measurements of two different design perspectives cannot be mixed. Although, user interface of the system can be considered as not tangible industrial object. UI similar as an industrial object provides the necessary functionalities to the users, through its visual representation. The main difference is that UI has no physical existence in the real world and it can provide the services only through special environment, such as computer, phone, tablet etc. Hereafter, we will go more deeply in this correspondence by applying industrial design principles to graphical user interface development.
Process-Oriented Quality Attributes [4]: The following principles are process-oriented quality attributes of Software design [4]. They are applicable for development process of the software system: 1. Feasibility – executable/doable design process
26 2. Simplicity – simple, straightforward, not complicated (Also known as KISS – Keep it simple, stupid) 3. Manageability – easy to manage development process 4. Quality product – leads to required SW quality 5. Reliability – high success probability 6. Productivity – productive work of SW engineers 7. Time to market – SW is developed within required time 8. Risk – minimal probability of failure, minimal consequences if failure occurred 9. Resourcefulness – economical use of resources 10. Technical requirements – use of required equipment, tools and technical skills of people 11. Material requirements – use of required resources 12. Legitimacy – allowance according to laws, rules, regulations 13. Environment friendliness – minimal harm to environment (pollution) In our study, we are going to develop a chat system, which means that the development process will take place. Although, it would be better to work out chat using development process principles with a team of programmers. However, in our case, the chat system will be developed by one programmer. Therefore, application of these principles will not make much sense. However, some process-oriented quality attributes of Software design such as feasibility, simplicity, reliability etc. are useful and make sense even with absence of a team. We will take into consideration applicable principles during the development process, but we will not compare principles of software development process with industrial design principles. The study about software process management is out of scope of our research.
Software Architecture Microsoft team has defined software architecture “as the organization or structure of a system, where the system represents a collection of components that accomplish a specific function or set of functions” [18]. In other words, software design describes the software architecture. In our study, we will present the main software architecture principles, design practices and rules according to Microsoft team [18]. Software architecture principles by Microsoft Patterns & Practices Team [18]: 1. Separation of concerns principle – minimization of functionality overlap to achieve high cohesion, low coupling 2. Single Responsibility principle – each component is responsible for specific functionality 3. Principle of Least Knowledge – a component or object knows only about its own internal details (Also known as the Law of Demeter) 4. DRY (Don’t repeat yourself) – duplication avoidance 5. YAGNI ("You ain’t gonna need it") – design only what is necessary
27 According to Microsoft team, the following factors could simplify the designing, implementing, deploying, testing, and maintaining process of the application. Microsoft design practices [18]: 1. Consistent design patterns – make compatible tasks and components design within each layer 2. No functionalities duplication – make the only one component providing specific functionalities 3. Composition instead of inheritance – use composition instead of inheritance, because inheritance decreases the dependency between parent and child classes 4. Coding style and naming convention – use styles and naming standards, to improve maintainability. Although it is one of Microsoft’s design practices, the following example demonstrates inconsistent style, found in the source code of Microsoft standard C library of Visual Studio 2013 (strdup.c):
5. { _ERRCHECK(strcpy_s(memory, size, string)); return memory; }
Here, “return” statement should have been indented like the statement above it, because they are on the same level. Wrong indentations decrease readability and understandability of the source code, which leads to lower quality software.
The importance of this question to the community of developers can be demonstrated by infinite argues and discussions about that. Big companies, such as Google7 and G. S. Services8 have their coding style guidelines. Recently statistics about popular coding convention on GitHub were published9.
6. Automated QA techniques – use automated quality analysis techniques and Unit testing during development 7. Consider SW deployment– determine required operational metrics and data Microsoft rules for application layers development [18]: 1. Separate independent features – minimize functionalities overlapping 2. Precise communication between layers – do not allow every layer to communicate with all other layers because it complicates management and understandability
7 http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml 8 http://geosoft.no/development/cppstyle.html 9 http://sideeffect.kr/popularconvention
28 3. Use abstraction – define common interface or shared abstraction that must be implemented by interface components 4. Distinguish logical layers – use one logical layer for the same types of components 5. The same data format within a layer or component – keep the data format consistent within a layer or component, because every time data conversion will need translation implementation Microsoft rules for components, modules, and functions development [18]: 1. Object should not rely on internal details of other or objects – object knows only the called method, but does not know how it is processed. 2. Do not overload the functionality of a component – apply single responsibility and separation of concerns principles 3. Deployment scenarios – understand components communication, their running boundaries 4. Components usage and behavior – define access and behavior internal functionalities of components
Source Code In this section, we are presenting rules and ideas invented to improve the quality of the code. It is extremely important to write a clean code, as said Robert C. Martin [20] – “the ratio of time spent reading vs. writing is well over 10:1. We are constantly reading old code as part of the effort to write new code”. Therefore, easy, readable, understandable and bug-free code makes developers life easier. Although, there are so many different rules formulated by software professionals. In our study, we are selecting the most important principles formulated by well-known experts in programming. All software solutions, that simplifies the lives of developers, makes as much sense as any industrial design solution, like, for instance, making chairs stackable10, they also simplifies the lives of current users – people. Principles of object oriented class design by Robert C. Martin [15] 1. Single Responsibility Principle – Each class has only one single responsibility 2. Open Closed Principle – Modules can be extended, but cannot be modified 3. The Liskov Substitution Principle – “Derived classes should be substitutable for their base classes” [15] 4. The Dependency Inversion Principle – every dependency must target interface or an abstract class and never a concrete class 5. Interface Segregation Principle – service interface must have only methods that are used by client
10 http://it.phaidon.com/agenda/design/video/2012/february/15/better-buy- design-seven-series-chair/
29 Following six principles of object oriented package architecture design formulated by Robert C. Martin [15] Three mutually exclusive principles of package cohesion [15]: 1. The Release Reuse Equivalency – all of none classes of the package must be reusable. Old package must be also supported after release of new package 2. The Common Reuse Principle – group classes that will be reused together in the same package. 3. The Common Closure Principle – group classes that change together in the same package to minimize number of packages changed Three package coupling principles [15]: 4. The Acyclic Dependencies Principle – The dependencies between packages should not create cycles 5. The Stable Dependencies Principle – changeable package should depend on more stable packages 6. The Stable Abstractions Principle – stable packages cannot be extended therefore they should be abstract ‘Clean Code’ Principles Software professionals Robert. C Martin and Dean Wampler have written a book: “Clean Code: A Handbook of Agile Software Craftsmanship” [20] and it is full of recommendations, heuristics, disciplines, and techniques about how to write a good software. The following list presents some of ‘Clean Code’ principles, stated in R.C. Martins book: 1. Names of variables, functions, arguments, classes, packages etc. must be: a. meaningful b. clear c. descriptive, even if they are long Examples: Use of unclear names in source code: ‘number’ vs. ‘count’ and ‘index’ Use of word ‘number’ when giving names. In English, it can mean both the count and the index. Instead, we should use specifically ‘count’ or ‘index’. ‘isEquals(a,b)’ vs. ‘compare(a,b)’ The names of boolean functions and variables should start with a verb. For instance isEquals(a,b) vs. compare(a,b), statement ‘if (isEquals(a, b))’ is much more clear than ‘if (compare(a, b))’, because name ‘isEquals’ reflects the meaning of the result of the function (what we are interested in in the end), while name ‘compare’ only reflects the action. Example: Use of one-letter variables, mixture of lower/upper letters and numbers, no indentation. number ‘0’ or letter ‘O’ and number ‘1’ or letter ‘l’
int a = l; if (O == l)
30 a = 1; else l = 0;
In the above source code, the values are unclear: whether it is number 0 or letter O and number 1 or letter l. Such naming should be avoided, because it is very confusing and unclear. 2. Functions: a. functions should be as much small as possible b. Blocks should be one line long within if, else, while statements c. Do One Thing – function should do only one thing and cannot be divided into sections d. Less arguments – the best is when function has no arguments. Function could have at most three arguments
Example [20]: function that changes value if such exist. Returns true if the value was successfully changed and false otherwise.
public boolean set(String attribute, String value);
Firstly, this function has unclear name, and secondly, it violates “Do One Thing” principle, because it does two things: first, it checks for existence of the passed attribute and second, assigns new value if such attribute exist. This could lead to unclear code such as:
if (set("name", "Jacky")) { ...
Hence, we cannot understand from the above code, what this function is doing. This problem could be solved by separating the function into two functions:
public boolean attributeExist(String attribute); public void setAttribute(String attribute, String value);
When function is separated, then every function does only one thing and the use of these functions in the code is much clear:
if (attributeExists("name")) { setAttribute("name", "Jeck"); ...
e. DRY principle [21] – Don’t Repeat Yourself – eliminate data duplication. The use of attributeExists and setAttribute functions are violated by DRY principle, because we repeat the same parameter ‘name’. Every time when we will need to assign a value to an attribute, we will need to check first for its existence. The solution is to introduce new setAttributteIfExists function:
31 public boolean setAttributeIfExists ("name", "Jeck")) { if (attributeExists("name")) { setAttribute("name", "Jeck"); ...
3. Comments: a. Must be informative, but shouldn’t have too much information and examples b. Write a clean code instead of commenting it c. At the beginning of every source code write a legal comments such as copyright and authorship statements d. If possible, write functions or variables instead of comments 4. Error handling: a. Prefer Exceptions to Returning Error Codes – Error codes means that the caller must deal with this problem immediately, exceptions allows error processing. b. Write Try-Catch-Finally Statement First c. Create informative error messages, which allows determining the source and the location of an error. Good coding style makes easier code readability and understandability improving maintainability and extensibility. Therefore, the Robert. C Martin advises always write a ‘clean code’ which leads to high quality software. The Pragmatic Programmer rules We have found another set of programming rules in A.D. Hunt’s book: “The Pragmatic Programmer” [21]. The following list represents some of them: 1. Make quality a requirements issue by giving early for users to play with software. Usually their feedback will lead to a better software. 2. Make your documents look good 3. DRY – Do not repeat yourself. Avoid duplication. 4. Avoid global data – it could create troubles and complicates understandability and maintainability 5. Keep your code decoupled – write shy code – modules, which do not depend on other modules implementation (Least Knowledge Principle) 6. Assign a value to each parameter 7. Always solve/fix find out problems (debugging) 8. Crash Early – make your code crash as soon as possible 9. If It Can't Happen, Use Assertions to Ensure That It Won't 10. The Law of Demeter – minimize coupling between modules 11. Configure, do not integrate – write configurable code “soft code” that is adaptable to change. 12. Refactor Early, refactor often – refactor when you need to extract details, generalize something or remove duplicates 13. Don't Use Wizard Code You Don't Understand – you won’t have a control on your application if you won’t be able to understand it 14. There Must Be an Easier Way!
32 15. Design to test – always keep tests in mind when you write a code. Test Early. Test Often. Test Automatically. 16. If you’ve found a bug, write a test – test will help to correctly understand the bug 17. Know when to stop – perfect code does not exist, programmers need to know when or where to stop Principle: Do not make me think Steve Krug wrote a book called “Don’t Make me think” [22] about human- computer interaction, websites and mobiles usability. The background of the book is that good software or websites should provide for users easy and direct performance of their intended tasks. Therefore, we would like this name of the book use as a principle of a good UI design.
3.2. Bad Software Design
In this section, we are going to define bad software design principles and show some examples of it.
Rotting Design The following four principles of rotting design were formulated by Robert C. Martin [15]: 1. Rigidity – difficult to change 2. Fragility – software breaks in many places after introducing a change 3. Immobility – software cannot be easy reused because it has high dependability from other modules 4. Viscosity – to implement a SW change is easier by using hacks than right methods viscosity is considered high The presence of one of these four principles demonstrates the need of code refactoring, because they are signs of a bad software design. Usually, they are called code smells.
Bad Smells in Code Code smells are symptoms of bad SW design, which indicate the need of refactoring. They are not bags and do not interrupt program functioning, but could create problems, bugs or failures in the future. The following list shows code smells by Kent Beck and Martin Fowler stated in the book “Refactoring: Improving the Design of Existing Code” [16]: 1. Duplicated Code – the same code structure in more than one place should be unified 2. Long method – too large methods, procedures or functions should be split 3. Large class – classes which are doing too much, usually have too much instance variables. The class should be extracted by bundling variables belonging to the same component
33 4. Long Parameter List – methods with long parameter list are hard to understand and difficult to use 5. Divergent Change – we need to make a single change, we need to do it in several places, instead of jumping on one single clear point and change the code there 6. Shotgun Surgery – one change affects many classes. Ideally, things should be arranged in such way, that one common change affects one class 7. Feature Envy – a class use methods of other class more than itself methods 8. Data Clumps – data, that are occurs together in several places should be made into their own object 9. Primitive Obsession – avoidance to use small objects for small tasks. Objects breaks the line between primitive and classes. Programmers may write a little class that are indistinguishable from built-in types of the language 10. Switch Statements – lack of switch statements in object oriented code 11. Parallel Inheritance Hierarchies – if class needs to be a subclass of one class, it is also must to be a subclass of another class. Duplication should be eliminated by ensuring that instances of one hierarchy refer to instances of the other 12. Lazy Class – a class that is not doing enough should be eliminated 13. Speculative Generality – presence of not required functionalities that maybe will need some day and maybe not 14. Temporary Field – presence of unused objects instance variables which could be extracted 15. Message Chains – client as object for another object, this object asks other object for yet another object etc. 16. Middle Man – encapsulate internal objects details 17. Inappropriate Intimacy – classes which have dependencies on implementation details of other class, should be split 18. Alternative Classes with Different Interfaces – methods with different names but the same behavior 19. Incomplete Library Class – usually it is impossible to modify a library class that we would like it to do 20. Data Class – data classes have only fields and getting, setting methods for fields. Although, these classes my take some responsibility 21. Refused Bequest – when subclasses do not need methods and data of their parents then it is a sign of bad hierarchy 22. Comments leads to bad code. Before willing to comment the code, try first to refactor it, afterwards the need of comment could disappear. In this chapter, we have described good and bad software design principles. Like dealing with industrial design, we have not found concrete and bounded set of software design principles. Software professionals are always emphasizing different software principles. Although, the general and main idea of ‘Clean Code’ [20] remains always the same – good code is easy to change, maintain, add new features, understand, it is not crashing etc. Principles, such as KISS, DRY, YAGNI etc. are overall, well-known, abstract and are used not only in software design, therefore we have noticed, that they are overlapping with software and industrial design principles.
34 4. Link between Software and Industrial Design
Firstly, we would like to explain the meanings of behavior and static features, as well as functional and observable properties. The general design theory is based on Yoshikawa’s mathematical design theory [23] which have been developed later to abstract design theory by Y. Kakuda and M. Kikuchi [24]. H. Zhu [4] claimed that this design theory helps to determine the proper set of entities from the infinite number of design spaces. Domain knowledge of each artefact (material entity) is associated to knowledge about artefacts combinations and relationships between functional properties and structural features. It forms a general theory of a design space that solves artefacts synthesis and analysis problems. Synthesis design problem is solved by finding appropriate structure that meets all functional requirements. Analysis design problem helps to find out the properties which the structure or part of the structure should be provided. For example, assume we want to design a chair. Hence, our design entity is a chair, which has functional requirements (functionalities) such as ‘to sit’ and ‘to move’, and properties ‘aesthetic’ and ‘lightweight’. During synthesis design, from the given functionalities, we will define such structure of a chair: ‘has a seat’ and ‘has a wheels’. In order to match defined structure we will extract some chairs such as bar chair, rocking chair and come up with temporary result: wheelchair and office chair. Further, we need to decide for which design choices we will go in order to meet the properties of our chair. It will solve analysis design problem and lead to the final design solution. Therefore, we will extract the wheelchair, because it does not correspond to our properties – lightweight and aesthetic. Our result will be the office chair. The following picture represents the general theory of design space explained above.
General theory of design space
Synthesis Analysis Functionalities Structure Properties design design
Figure 12. Representation of the general theory of design space
According H. Zhu [4], “The general theory of design space can be applied to software design in the study of the variety of software architectural elements”
35 by representing the domain knowledge of software architectural elements through a set of behavior and static properties. H. Zhu parallelize the general theory of design space to software design theory, based on Kazman [25] work about architectural elements classification. Software design space is formed from software architectural styles and they are classified according their behavior and static properties. Behavior properties describe architectural elements dynamic behavior through their run-time, for example, time for data transmission, data acceptance. Static properties describe the architectural element’s structure, characteristics and relationships to other elements and behavior features, that are not related to run-time events, for example ports, data flow channels. Functional properties (also called functionalities) describe objects behavior in specific situation, for example aesthetic, movable etc. Observable properties describe design choices. They can be observed or measured with use of instrument, for example, chair has a back support. H. Zhu defines the similarities between software and physical features: behavior and static features of an architectural element in software “are similar to the functional and observable properties of physical entity, respectively“ [4]. The following picture represents explained relationship between domain knowledge of software architectural elements and physical entities.
Domain knowledge Domain knowledge of software architectural of physical entities elements
Functional Behavior properties properties Similarities between design features Observable Static properties properties
Figure 13. Link between software features and physical entity properties
Consequently, we have combined the general theory of a design space shown in Figure 12 and the properties relationship represented in Figure 13. In addition, we are showing the place of industrial design principles and arrows where they are applied for physical entities and where they can be applied to software architectural elements. Consequently, Figure 14 summarizes the relationships between software and physical entities properties introducing the industrial design principles.
36 Requirements
structured into General theory of a design space Physical Objects Properties Physical Entities
Industrial Design Principles
applied to Functional Observable
Software similar Software similar properties Architectural Elements
Behavior Behavior
Figure 14. Properties of Physical Entities and Software Architectural Elements
General design theory explains the transition from objects requirements or functionalities to physical objects properties by building appropriate structure. For example, designing a chair we defined requirements such as ‘to sit’ and ‘to move’. From stated requirements, we deduce chairs properties, such as ‘movable’ and ‘aesthetic’. Physical entities properties can be functional or observable, also called attributes. Attributes are independent properties that can be measured or visually observed. Functional properties reflects an action, that can be performed by an object and they can be derived from attributes. For example, chairs attribute is ‘has wheels’ and derived functional property ‘movable’. As it was explained in chapter 2. Industrial Design, industrial design principles are applied for physical objects and their properties. According H. Zhu [4], software behavior properties (for example data transmission) are similar to objects functional properties and software static properties (for example ports, channels) are similar objects observable attributes. Therefore, because of properties similarity, we can assume the possibility of application objects principles to software architecture. Further, we will describe methods and cases of the application of industrial design principles to software product development.
37 4.1. Software and Physical Objects
In this chapter, we are going to focus on the relationship between interior software system and exterior industrial design. The software has no physical existence in real world. Hence, it cannot be explored through people’s tangible senses as any physical artefact can be. Although, the fundamental difference as it was pointed out by H. Zhu [4] is the invisibility of software comparing with other designs of physical artefacts. Hence, the application of any observable or measurable properties of physical objects will not be worthwhile for software. We assume, that author means the architecture of the system from end-users point of view, because their visibility is bounded by user interfaces. Exception is End-User Development (EUD11) that “enables end users to design or customize the user interface and functionality of software” [26]. Although in our case, EUD is not relevant to us because we will not provide changeability for users to our chat. Software systems design, which is about an internal structure of a software system, on the one hand, has little connection with industrial design, which is about the exterior. However, on the other hand, internal software system design for software developers is external, because it is with what they work and interact. Hence, the developers are also the users of the internal part of the system and from this point of view, the internal parts of the system become external for them. Usually in software development and maintenance process, the internals, such as software architecture and software code, are visible to everyone involved. The following picture represents the relationship between exterior industrial design, exterior user interface design and interior software system design as software architecture and code.
11 http://en.wikipedia.org/wiki/End-user_development
38 Software Product Physical objects
Visible User Interface Design relationship Industrial Design (Exterior) (Exterior)
Software System Design (SW Engineering) (Interior, but (!) Exterior from developers’ point of view)
Figure 15. Relationship between industrial and software design In our study, we are comparing the external and internal parts of software system with industrial objects. The internal components of software system are physical objects used by developers, as teapots are used by regular people. For example, the chair standing in public place always has new users who are sitting on (using) it. During the chairs production process engineers are calculating about everything that could make this chair comfortable, functional, and esthetic etc. Similar it is happens in software when, we are trying to develop a software, which will match all software quality attributes. Although, the main difference between software and industrial object, is that SW is changing with time when all industrial object are usually static. Hence, if software is successful, it will be maintained in the future and it will have new end-users. Therefore, maintainability is the main reason, why internal software design must be definitive, understandable and simple. Inadvertence of the current software designers could become crucial in the future. For this reason, we want to highlight the importance and provide suggestion for improving the internal parts quality to simplify the software maintenance. In our study, we offer to apply industrial design principles into the development of software architecture and code.
4.2. User Interface Design and Industrial Design
To separate users from developers in software engineering there is term end- users, which refers to expected software users without programming experience. Usually they have access to the lower software components through abstractions, such as graphical user and command line interfaces. User interface of any system is alike industrial object, it serves to provide
39 functionalities to end-users, who are regular people. Therefore, as an industrial object it must be functional (Industrial design principle 1), simple (Industrial design principle 15) and attractive (Industrial design principle 8). We consider these industrial design principles substantial in user interface design. We would like to give a further successful transfer from industrial design objects visual presentation to user interface design. It is trivial that there is slight difference between Braun physical calculator and iPhones calculator application by Apple, Braun radio and Apples iPod player. It is important to emphasize that Apple is the world’s most admired company12 and, until the first quarter of 2013, the most profitable company in the world13. Jonathan Ive, Apple’s senior vice president of industrial design “has long acknowledged the influence on his work of Dieter Rams, who was Braun’s head designer for nearly 30 years.”14.
Figure 16. IPhone calculator app vs. Braun’s ET44 calculator and Braun T3 pocket radio vs. the iPod From Figure 16 we can see that iPhone’s calculator app looks almost the same as Braun’s calculator15 designed by Dieter Rahms in 197816. Slight changes were done: bigger screen became possible due to new screen technology, buttons that were considered not so frequently used were hidden, however, the main design idea, including colors and shapes, was unchanged. It was similarly with Braun’s radio and iPod. These examples represent the existence of visible connection between software programs and physical objects. The presence of this connection does not necessarily mean that the application of industrial design principles and use of industrial products will have an impact on the quality of the final software. Our goal is to reveal whether application of good industrial design principles to our chat system means improving software quality.
12 http://money.cnn.com/magazines/fortune/most- admired/2013/snapshots/670.html 13 http://www.businessinsider.com/samsung-is-now-a-more-profitable-company- than-apple-2013-10 14 http://www.dailymail.co.uk/sciencetech/article-2200660/Did-Apple-inspiration- iconic-products-simplicity-Braun-designs-50s-60s.html 15 http://www.cultofmac.com/188753/the-braun-products-that-inspired-apples- iconic-designs-gallery 16 http://en.wikipedia.org/wiki/Apple_Inc._design_motifs
40 4.3. Model of Principles
In this section, we are describing in more detail the role of every industrial design principle in software in Table 3. Potential Application of Industrial Design Principles in Software. High-level concepts of industrial design principles application in software are defined in Figure 17. The following table contains all industrial design principles discovered in chapter 2.1. Good Industrial Design Principles. We have copied the definitions of each industrial principle and shown the correspondence between similar principles in software (if it exists) and specific industrial design principles. After it, we have described the potential application of each industrial design principle in Software. To discover the potential application of industrial design principles in Software, we have interviewed an expert, who preferred to stay anonymous. Our interviewer is Software and Web Engineer with nearly 10 years’ experience. With respect to Web development, he deals with front- and backend development more than 7 years. He has much research experience in web engineering, especially in the application of JavaScript and server side. The interview was organized in such way: at the beginning, we presented to expert the industrial design principles and definitions with all comments of the famous designers related to them. Then we asked the expert his opinion about possible application of exact principle in software, distinguishing the potential application in user interface and in the code. We also asked to explain how important is the exact principle and what situations it could be applied. Therefore, the part about potential application of each industrial design principle in software is written according to the expert words. We have included the most important facts have been mentioned by the expert.
Table 3. Potential Application of Industrial Design Principles in Software
Industrial Design Principle Accurate Definition Is thorough down to the last detail Similar Principles in Software Meets users expectations Potential Application in Software 1. Software product is accurate, if it meets users’ expectation. For example, if user press “play” button he expects that music is going to start playing. 2. Accuracy also means to keep detailed and accurate records. In simple applications, where the most important is the UI (for example notepad) details are not so important. Although in certain domains, such as industrial software, precise and detailed software, documentation, code, architecture are important.
41 3. Accuracy must be correct in measuring software; in other case, the software is useless.
Industrial Design Principle Adequate price Definition Has affordable price, low-cost Potential Application in Software 1. Adequate price means how much user is willing to pay for the software. It depends on the market, for example, he can be ordinary students or rich company. 2. It is difficult to lower the Software price (for example, as Software price can be using open source libraries, reusing software) without decreasing the quality. 3. The Software price depends on a product and on the people developing a product. To set a Software price it is important to see what your competitors’ price is.
Industrial Design Principle Aesthetic Definition Is well executed, beautiful Potential Application in Software 1. Aesthetic (simple) UI is more attractive, understandable and intuitive. 2. Aesthetic code uses coding style and naming convention, therefore such code is easy to understand and maintain. For example, short methods, correct names. We can see the beauty in aesthetic code. 3. If the code has many files, some documentation and diagrams are needed. In other cases, the code is more important than the documentation. Similar Principles in Software Make your documents look good [21] Coding style and naming convention [18]
Industrial Design Principle Appropriate shape Definition Has comfortable and suitable shape Potential Application in Software 1. Appropriate shape is applied in user experience domain. 2. Programs should follow appropriate paradigms in UI development, unless the developers want to create a new paradigm. For
42 example, there is a Siri (Apple) and google introduced “Google Now” (cards with changing colors) which is a changing paradigm in user experience. 3. Appropriate shape in code is simply following coding style standards and coding conventions (for example naming, parenthesis, spacing). It is related to aesthetic or the code. 4. For example, python has an appropriate shape build like as feature of programming language. There are requirements for exact place of the elements. Similar Principles in Software Consistent [14] – Is well structured, organized, has appropriate information hiding
Industrial Design Principle Attractive Definition Has good visible presentation Potential Application in Software 1. In terms of the product, the most important is positive influence into user emotions. For example, in Facebook, in the center of the user interface is the user himself. 2. Attractive code is a consequence of aesthetic and appropriate shape code. 3. Attractive documentation follows certain topographical rules, for example, spaces, text font, limiting number of characters, footnotes, colors.
Industrial Design Principle Branded Definition Has its own mark Potential Application in Software 1. The brand in term of user interface means the uniqueness of the product. In that case, the product needs to be branded only when it has to add something completely new to the market (for example, iTunes was the first media player with such design) or the market is full of unbranded products. 2. In terms of naming, logo of the cool brand adds value to the product.
43 3. Brand and advertisement of software product increase its popularity. By the name, users can recognize, search, speak, and advise, critique developed software. The more users know about the software, the more it is popular.
Industrial Design Principle Environmentally friendly Definition Considers environment protection, energy conservation and re-use Potential Application in Software 1. It is difficult to achieve it in software, because there is no direct need to burn trees in order to develop something. 2. It is important for mobile applications developers or companies because they must be environmentally friendly by the law. 3. Usually it has to deal with Hardware rather than software. In software, it is related to performance, for example, waiting time for the results, efficient use of resources. Similar Principles in Software Efficient [14] use of resources
Industrial Design Principle Ergonomic Definition Comfortable, efficient object Potential Application in Software 1. Ergonomic is consequence of the successful achievement of the following principles: accurate, aesthetic, attractive, appropriate shape, functional, optimal shape, simple, understandable, unobtrusive and usable. 2. UI is ergonomic, when it is functional, comfort and user friendly.
Industrial Design Principle Evolutional Definition Uses the latest technology Potential Application in Software 1. It depends on type of users and how they feel with the latest technology. 2. Developers usually prefer stable stuff; therefore, it is risky to use latest and not stable releases. 3. It is also depends on the product being used.
44 Similar Principles in Software Automated QA techniques [18] – Quality Analysis techniques and Unit testing during development
Industrial Design Principle Functional Definition Does what it must to do Potential Application in Software 1. Software should perform a function that it is supposed to perform. It must provide the users exactly what it is promising. 2. The code is functional, when it performs what it says to be performed. For example, if the function says that it does the addition, it means, it should perform only the addition and not the multiplication or addition and then multiplication. Functions should return the expected result. 3. The source code must deliver what it is promising to deliver. Similar Principles in Software Implementable [14] – Has theoretically computable and achievable functions with available software and hardware Modular [13] – High cohesion, low coupling Single Responsibility principle [18] – Each component is responsible for specific functionality Separation of concerns principle [18] – Minimization of functionality overlap to achieve high cohesion, low coupling Principle of Least Knowledge / Law of Demeter [18] – A component or object knows only about its own internal details
Industrial Design Principle Honest Definition Is what is really is Potential Application in Software 1. The software product is honest if it contains only the real facts about the system and doesn’t hide any information 2. It is related to market and branding. If the product is not meeting the expectations of the users, it is useless. 3. The source code must be honest from users’ point of view. If it says that it returns the random number,
45 it must always return the random number.
Industrial Design Principle Innovative Definition Was not yet created before, new Potential Application in Software 1. Program, as a product does not have to be necessary innovative, if it is meeting the demands of its users. 2. Software has to be innovative only when it is useful for the users and there is not always the correspondence between creativity and the usefulness. For example, when Siri came out, it was innovative and useful. Therefore, it is not mandatory feature. 3. Innovations in source code help to write simpler code. 4. Frameworks in source code can enable creativity and help to write the code faster.
Industrial Design Principle Long lasting Definition Never becomes antiquated, not fashionable Potential Application in Software 1. Long lasting means maintainable software. 2. Users are always willing updates, even when software perfectly performs its functions. 3. Even operating systems are updated. 4. Long lasting software is needed only in special domains, for example ERPs. 5. From source code point of view there is no need to do a perfect objects orientation and encapsulation. More important is to do a function, which performs the promised action avoiding over- engineering. Similar Principles in Software Flexible [14], changeable, maintainable
Industrial Design Principle Market Placement Definition Is easy to introduce in the market Potential Application in Software It is important to know user demands and similar available software on the market
46 Industrial Design Principle Optimal shape Definition Consists of must to be parts Potential Application in Software 1. It is close related to simplicity and minimalistic design.
Industrial Design Principle Safe Definition Has no danger for health Potential Application in Software 1. It means safe transactions, password security. 2. To avoid loud and unpredictable sounds in software. 3. It has to conform to laws. Similar Principles in Software Safety – checksums are backups are performed Security passwords are encrypted and defended from attacks.
Industrial Design Principle Simple / Pure Definition Concentrates on essential aspects, has as little design as possible Potential Application in Software 1. UI contains only needed elements. 2. Code contains only necessary components, documentation only the necessary information needed to understand the code. Similar Principles in Software KISS [4] – “Keep it Simple, Stupid” – simple, straightforward, not complicated Practical [14] – Modules provides only required facilities, not more or less. DRY (Do not repeat yourself) [18] – Duplication avoidance. YAGNI ("You ain’t gonna need it") [18] – Design only what is necessary. No functionalities duplication [18] – Make the only one component providing specific functionalities
Industrial Design Principle Understandable Definition Is self-explanatory, intuitive and concrete Potential Application in Software 1. User interface has to be intuitive for its users 2. The code should be understandable for developers Similar Principles in Software Conceptual integrity [13] – Adhering to one single concept, predictability, understandability. Avoid global data [21] – It could create troubles and complicates understandability and maintainability.
47 Do not make me think [22] – Good software or websites should provide for users easy and direct performance of their intended tasks
Industrial Design Principle Unobtrusive Definition Clearly fulfills a purpose Potential Application in Software 1. It is related to understandability and functionality. 2. The user discovers the needed function only when he needs it. The UI should not be overflowed with buttons, textboxes etc. when the user usually does not need .them. 3. It must contains only those functionalities, which the user needs, without annoying properties. For example, unrequired explanations of Words office assistant ‘Clippy’ that annoyed users with continuously saying something. 4. Everything, that breaks the standard flow of programs and their behavior, can be unexpected to user, is unobtrusive Similar Principles in Software Standardized [14] – Is standardized documented, well-defined, has familiar notation
Industrial Design Principle Usable/Useful Definition Satisfies the needs and usefulness criteria’s Potential Application in Software 1. UI is usable, when there is an elegant interaction between UI and the user. 2. The UI is usable if the user easy understands and learns to use it. 3. Software is useful if it satisfies users’ needs and delivers the needed functionality Similar Principles in Software Consider SW deployment [18] – Determine required operational metrics and data. Portable [13] – Independence from environment Adequate [14] – Meets stated requirements
To sum up, we can highlight that for some industrial design principles, we have discovered the corresponding principles in software design, and they perform the same or similar functions, meanings or ideas. Although, we almost have
48 not found any exact intersection between software and industrial design principles. The exceptions are some common design principles, such as KISS, YAGNI and DRY. All industrial design principles are not new in Software and have its role and specific application domain. Industrial design principles can help in understanding existing software principles and add new points of view on software development and software product, which consequently can lead to qualitative software. Research Model in Figure 17. Research Model, it contains all discovered in chapter 2.1 Merged Good Industrial Design Principles , which have been written inside object. These principles are divided into two groups: principles that can be applied to the code and user interface and principles that can be applied only to software product, because they are related to price, market placement and brand of the software. The principles with number one are applicable to software, because some of them are already principles of software design (for example, functional, safety, usable). To other principles, we have found direct or indirect correspondence and potential application of these principles to Software user interface or the code, which is described in Table 3. Potential Application of Industrial Design Principles in Software. The most of the industrial design principles are not mentioned as Software principles in chapter 2.1 Principles of Good Software Design. Although, some of these principles (such as attractive, aesthetic, accurate) are mentioned as a principles of UI design. Some of them have other formulations (more specific and more complex) and some are not mentioned at all, although, all these ID principles can be considered Software principles. The principles with number two are about finished and deployed software product. Mainly they are addressed to raise the revenue from deployed software and make it successful on the market. All shapes in Figure 17 represent the sets of principles belonging to specific area of design. All industrial design principles intersect with software product principles. This representation means that they all can be applied to software. The most distinguishable software parts are the code and user interface; consequently, in our visualization, they are subsets of software product. Therefore, we can apply all industrial design principles separately on every discipline in software development, excluding last three (red color) principles, which are related to final software product. When software can be deployed, it can be evaluated and considered as any object of industrial design, with the main difference – software is virtual and objects are real.
49 User Interface
Code
Object
Functional Simple/Pure Understandable Environmentally friendly Accurate Aesthetic Appropriate shape Attractive 1* Ergonomic Honest 1* + 2 Long lasting Optimal shape Safe Usable/useful Innovative Unobtrusive Evolutional
Adequate price 2* Branded Market placement
Software Product
Industrial Design Principles: 1* – can be applied to software code and user interface 2* – can be applied to software product 1*+2*/ All – are applicable to Software system
Figure 17. Research Model
50 4.4. Related Work
We have discovered, that industrial design principles are overlapping not only with quality attributes (such as functionality, usability and efficiency) from ISO/IEC 912617, but also with quality characteristics of mobile applications. The study “Defining Relevant Software Quality Characteristics from Publishing Policies of Mobile App Stores “ [27] by L. Corral, G. Succi and A. Silitti, discovered a Mobile App Quality Model, which “focus on the characteristics that deliver more value to the quality requirements of the app stores and dismisses the less relevant quality characteristics”. The model contains two traits of quality characteristics: development-oriented and user oriented. Our application of industrial design principles was also divided into external and internal points of view. Internal parts of the system are development oriented and we speak mainly about the code. Whereas external parts of the system are user, oriented systems because the user experience and interact with the system and it is user interface. Additionally, our discovered industrial design principles, their interpretations and potential applications correspond to the most weighted quality characteristics (it was calculated by obtaining the QCW) from Mobile App Quality Model. For example, the first development oriented quality characteristic is ‘Functional Suitability’, which corresponds with principle functional. Sub characteristics of ‘Functional Suitability’ are ‘Completeness, correctness, appropriateness’. We have interpreted these quality characteristics as accurate, ergonomic, and appropriate shape principles. Other development oriented quality characteristic – ‘usability’ and its sub-characteristic “user interface aesthetics” are directly related to the same industrial design principles transferred to software domain. The overlapping and similarities between mobile apps quality characteristics are out of scope of our study, although the existence of these relationships shows the importance and the usefulness of the application of industrial design principles to software design. We propose to continue an aggregated study on the application of industrial design principles to mobile applications design.
17 http://en.wikipedia.org/wiki/ISO/IEC_9126
51 5. Unibz Chat System
Informal discussion among Unibz students about the potential usefulness of Unibz live chat showed that it would be handy to have it. The rooms (channels) in this chat correspond to the real university classrooms (e.g. “E531”). Additionally, private conversations are supported. The detail requirements of a chat system will be described in the next chapters. Therefore, at the Free University of Bolzano, we defined: Problem: There is no centralized way for Unibz students to communicate with each other about a lectures/exercises etc. Free University of Bolzano has any student-friendly internet tool that could meet the academic, social, and psychological needs of its students. Proposed Solution: Implement Unibz chat with virtual rooms corresponding to real lecture rooms, kind of virtual reality chat. Using this university chat system physically presented in the class people are able to ask immediately each other about the topic without interrupting the lecturer. Obviously, for shy students to ask something in the chat is easier, than eye by eye in oral. During the labs and exercises, students can contact the professor or assistant in the chat fast, simply, anonymously (if preferred) and directly. Students, who are absent, are able to use this chat to get some information about what is going on in the classroom, like the homework assignment. We believe that thanks to all this advantages, this chat could become a new university e-learning technology, which could improve the learning process for students and simplify professor’s work. Computer: User A Chat server Web browser
KiwiIRC Web Client
Smartphone: User B
IRC server Web program browser
Figure 18. Chat System Architecture
52 The main idea is to use IRC (Internet Relay Chat) protocol for the chat. It is justified by the great availability of ready-to-use IRC clients – for desktop (e.g. mIRC18), web (e.g. KiwiIRC19) and mobile platforms (e.g. androIRC20).
However, to make such system, an IRC server (or IRCd21) is also required. All the existing IRC servers strictly support IRC protocol. Strict IRC support is not suitable for the proposed requirements because, for instance, rooms (channels) in IRC are not permanent – they are created when the first user wants to join an inexistent channel and are destroyed when the last user leaves the channel. To fulfill the requirements, we need a permanent and fixed list of channels. The common solution to such kind of problems is using different IRC services22 like ChanServ and NickServ, which are automated bots 23 who try to enforce some constraints on an IRC network. ChanServ, for instance, is a virtual user, who would never leave some channel, which should never be destroyed. Therefore, such IRC networks become very complex systems because of evolutionary changes and new functionalities addition. Our proposed solution is to simplify IRC, rather than complicate. For it, we have developed from scratch a custom IRC server, which would fulfill the requirements without needs of complex bot systems. It will still support IRC protocol, making it possible to use all the existing IRC clients to connect to university chat network. Therefore, in comparison with other mature chat systems like full IRC, our chat should be much simpler to use and maintain, because it will contains the only needed features. It is also much easier to implement a new feature (like fixed rooms list corresponding to the university real rooms) in a simple and custom-made program, rather than extend such heavy systems as contemporary IRC servers/bots infrastructure. To sum up the described above, the overall system will look like as described in Figure 18. Chat System Architecture. The IRC server will run on a university computer and will serve anyone connected with an IRC client. Users can enter the chat through their web browser from computer, phone or tablet by simply typing URL address of the chat. Browser will send a request for connection to KiwiIRC web client on the chat server machine and users will be able to interact in the chat. Plan of work: The work is divided into 2 main parts: IRC server program development from scratch and chosen IRC client customization, redesign, and deployment. IRC server program will be developed in C++ using “asio” library24, which has good support for asynchronous networking. The server should run on Mac, Linux
18 http://www.mirc.com/ 19 https://kiwiirc.com/ 20 http://www.androirc.com/ 21 http://en.wikipedia.org/wiki/IRCd 22 http://en.wikipedia.org/wiki/Internet_Relay_Chat_services 23 http://en.wikipedia.org/wiki/Internet_bot 24 http://think-async.com/
53 and Windows. IRC Web Client will be customized according Unibz design and our defined requirements.
5.1. State-of-the-art Review: IRC Clients
Our chat client is accessible through the web browser therefore we need Web client. Additionally, we need to customize this web client in order to have predefined list of channels (rooms) and university user interface. Hence, this client must be Open source. For this reason, we have searched in internet for Open source web clients. The following table contains all the found web clients and their features.
Table 4. IRC Clients
Client Unicode Distribution Latest Visual Popularity Comment Full support model stable Channel (place in client (UTF8) release List Google results)
ChatZilla Yes Free software July 7, - - Support only Yes 25 2013 Mozilla browser
KiwiIRC Yes Free software September Yes 1 Channel list in Yes 26 23, 2013 separate window with search and filtering
Mibbit27 Yes Textual Adbar Web Limited 3 Channel list Yes application, outputted no version directly to channel as a text
25 https://addons.mozilla.org/en-US/firefox/addon/chatzilla/ 26 https://kiwiirc.com/ 27 https://www.mibbit.com/
54 Client Unicode Distribution Latest Visual Popularity Comment Full support model stable Channel (place in client (UTF8) release List Google results)
qwebirc No Free software February No 2 No channel list Yes 28 13, 2012 support
Scrollback Yes Free software 2013 No - One channel Chat No 29
CGI:IRC30 - - - No 5 - Yes
WsIRC31 - - - - 4 Web site is not - working
lightIRC - - - - - Flash IRC client. - 32 Is not supported by some browsers
IRC Clients defined features analysis:
28 http://qwebirc.org/ 29 https://scrollback.io/ 30 http://cgiirc.org/ 31 http://www.wsirc.com/ 32 http://www.lightirc.com/
55 Unicode support (UTF8) – Support for all international languages and characters Distribution model – I would like to have free software Latest stable release – shouldn’t be more than one year Visual Channel List – special UI for viewing/searching/joining rooms Popularity – the more popular IRC client, the higher place it occupies in Google results. Full Client is necessary feature, because I am not interested in one-channel clients etc. KiwiIRC is the winner, because it is the only client that has visual channel list in separate window with search and filtering. KiwiIRC is a full client, it supports Unicode, it was the first in Google results and it is free.
5.2. Industrial Design Principles in the Documentation
In this sub-chapter, we present our simple and short documentation. The possible application of industrial design principles to the documentation and user manual are described in Table 5. During a seminar on Agile Software Development, software engineering expert Charlie Poole33 opined about the meaning of UML diagrams and pointed out that they need show the overall system overview of the system and systems interaction with user. Usually UML diagrams are quickly drawn on the board and erased afterwards. Our anonymous expert in interview expressed the similar opinion about them. Therefore, to document our system we will use only few UML diagrams to represent it. The following Use Case diagram represents chat participant interaction with a with a chat system.
33 http://pooleconsulting.com/
56
Figure 19. Chat System Use Case diagram
Details to every use case adds user story cards, which can be found in Appendix. The deployment diagram presents the physical view of the whole chat system.
IRC server is running on a chat server machine (chat.inf.unibz.it) and serves clients by IRC protocol. A web interface to the same IRC server is provided via
57 KiwiIRC. It is a Node.js application that runs on the same physical machine as IRC server. For web client to be as beautiful and consistent with the style of Unibz as possible, a modified skin of user interface is installed. A client with a browser opens webpage http://chat.inf.unibz.it, sees the Unibz skin and can use the university IRC network via web interface provided by KiwiIRC. The Industrial design principles application to Unibz chat system documentation and user manual:
Table 5. Application of Industrial Design Principles in Software Documentation
# Principle Application in the documentation 1 Accurate In software accuracy means, that it meets users’ expectations. In order to increase accuracy of our system and simplify users’ understandability of the system, we have made User manual, which can be found in Appendix of this study. 2 Aesthetic To draw UML diagrams we used WhiteStarUML34 tool, which makes good- looking diagrams. We used appropriate and characterized colors in diagrams and user stories to make the documentation more aesthetic and beautiful. Although, we do not pay a lot attention on it, because it is not on what we should concentrate the most. 3 Appropriate The UML notation is already a feature of shape appropriate shape, because all the diagrams use its own distinguishable notations and meanings. 4 Attractive We have created a user friendly and good looking manual with minimal amount of text and pages (chat system manual has only 3 pages, which contains 4 screenshots and commands). 5 Environmentally Documentation is simple and understandable; friendly therefore, we believe that there will be no need to print it. If still there will be a need to print it, less pages will be used. User manual is short, simple and understandable. It will be available to download from web page. We believe user will not print it. 6 Evolutional We used UML2 to draw our diagrams
34 http://sourceforge.net/projects/whitestaruml
58 7 Functional The documentations, diagrams and user manual deliver only necessary information, what they should and promise to deliver to the user. Therefore, we can say they perform this function 8 Honest Our documentation describes the real system and does not hide anything 9 Long lasting All user manual diagrams are stored in changeable formats; therefore, they could be easy changed in the future, without redrawing or rewriting from scratch. 10 Optimal shape Minimalism and simplicity guarantee optimal shape. The amount of our diagrams and the number of pages in user’s manual depict it. We prefer to allow the user to experience the system yourself, rather than spending time on reading the manual. 11 Safe Our documentation completely conforms to the laws. We use only legal information and available tools. 12 Simple / Pure KISS is the main principle of the whole our chat system, therefore we try to reach everywhere the maximum simplicity, especially in the documentation. 13 Understandable Simplicity, accuracy and functionality increase the understandability. We tried to follow all of these principles in order to create intuitive documentation and manual. We can do it by trying to think about users’ emotions, knowledge, and the way he is going to interact with the system. 14 Usable/ useful Documentation will be usable when the user knows how to use it. To increase usability helps its simplicity. Useful documentation delivers only user required information.
In modern software development methodologies documentation quality is a lower priority compared to a source code. The working undocumented function is much better than lots of documentation that could become useless due to changing environment or fast technology evolution. We quite agree with opinion that the quality of documentation does not play so important role. Exceptions are some specific domains, such as bank management systems or medical software. Therefore, we propose to concentrate only on those industrial design principles, which serve to simplify and minimize the code documentation.
59 5.3. Industrial Design Principles in the Source Code
As we have already mentioned in chapter 4, source code and internal structure of a program can be considered as if they are industrial objects. Following this statement, as example we can take door handle that has to be intuitive and understandable to door handle users. Here we are dealing with source code and it also has to be intuitive and understandable to source code users, other programmers and also to the author himself, as it is very easy to forget even your own code when you don’t work with it for couple of months. In this sub-chapter, we are describing the application of some selected industrial design principles to the source code of the chat system. Application of Accurate and Functional Principles In case of an IRC server, we are interpreting accurate and functional principles as compliance with IRC protocol specification (RFC 1459, RFC 281235). We strictly followed the RFC36 in the commands implementation. Application of Appropriate Shape and Optimal Shape Principles Appropriate shape we are interpreting as implementation of exact use of IRC protocol, and elegant implementation of the messages parsing. Optimal shape according to our interpreting means that the way of implementation should be as easy as possible with as fast as possible performance. As an example of one of the most complex command, we present “JOIN” message handler (request for entering rooms). According to the RFC, this command has one argument – comma-separated list of channel names user wishes to join. There is, however, one exception – when channel list is one symbol “0”, then the command is a special request to part (exit) all joined channels. This is how we have implemented the join handler: bool HandlerJoin::handleCommand(Server& server, Client& client, const char* /* command */, std::size_t argc, const char* argv[]) { if (argc < 1) { MessageFromServer::SendErrNeedMoreParams(server, client); return false; }
string channelList = argv[0];
// Handling special argument "0" which parts all channels if (channelList == "0") { HandlerPart::PartAllChannels(client); return true;
35 http://tools.ietf.org/html/rfc2812 36 http://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands
60 }
// For each channel in comma-separated list of channels for (string channelName : split(channelList, ',')) { Channel& channel = server.getOrCreateChannelByName(channelName);
// Only joining if the user is not already on the channel, // otherwise doing nothing if (!client.isOnChannel(channel)) { // Adding the client to the channel and the channel // to the client's list of channels he is on channel.addClient(client); client.addChannel(channel);
// Notify other all channel members (including the // client joined) about the joining channel.broadcast(MessageFromClient::Create( client, "JOIN", channel.getName()));
// Sending channel's topic to the user HandlerTopic::SendTopic(server, client, channel);
// Send the list of channel users to the client HandlerNames::SendNames(server, channel, client); } }
return true; }
Application of Aesthetic, Attractive, Honest, Pure, Understandable, Unobtrusive and Appropriate Shape Principles In chat system implementation, we have tried to write a ‘beautiful’ code. It means that the code is relatively short, straightforward, and consistent in style and naming conventions. The names themselves are also descriptive and at the same time as short as possible (can be called “appropriate”), making this code look like a literature in English understandable even to non-programmers (follows the “literate programming” idea of Donald Knuth). Application of Environmentally Friendly and Safe principles In software, environment friendliness is about effective use of resources, such as network and CPU time. High performance was the top goal when developing our server. Firstly, the server is written in C++. Secondly, asynchronous sockets are used for all network operations, allowing the server to use as little OS overhead, as the current technology allows. This also allows the server to potentially handle tens of thousands of simultaneous users (solves the “C10k37 problem”). Thirdly, the server itself is written very efficiently.
37 http://en.wikipedia.org/wiki/C10k_problem
61 As an example, consider a case when a message sent to channel should be broadcasted to all users who are on this channel. Class Client in the server is responsible for queuing output messages, sending them to corresponding clients, and then discarding. The simplest solution would be to give each client his own copy of the message, which would be kept as long as it needs to send and then discard. This leads to wasting memory resources. Our solution is to share one message among all clients who got it, and use std::shared_ptr (a new feature of C++11, that came from Boost C++ library) to do the reference counting and discarding the message after it is not used by any client anymore. Here are some details of how it is implemented: class Client ... { ...
/** * The output message queue. Every message first is stored here * and removed after is was sent. */ std::queue
...
void send(const std::shared_ptr
... };
Application of Evolutional, Long lasting, Optimal Shape, Simple and Useful Principles A program can be considered evolutional if it uses the latest technology. Our IRC server uses a lot of that. First, as we already mentioned, it uses asynchronous I/O that has smaller overhead than the “classic” blocking I/O. Second, it uses the latest version of C++ language, C++11, that allows us to use some convenient and effective solutions. Long lasting program is the program that is easy to maintain, therefore good quality programs are easy to maintain. We tried to develop as possible easy maintainable software by using IRC protocol, the latest technologies and simple, optimal solutions in the code. As an example, we will present one simple and understandable solution that became possible because of the use of the newest C++ features. In IRC protocol, clients and servers exchange messages whose format is described by RFC 1459 and RFC 2812. An IRC message is an ASCII string terminated by CRLF characters with maximum length of 512, including the terminal characters. In contains a command (a word) and arguments (also words) separated by spaces. The last argument, if preceded by a semicolon,
62 can contain space characters. An example of an IRC message is “PRIVMSG #Unibz :Hello everyone!”. The problem is to create such messages of different formats in many places in a program. In each of such places, the number and the type of the arguments differ. It might be, for instance, four arguments of type “const char*” or three of type std::string, or a mixture. Moreover, we want the most effective solution. The simplest (and the most effective) solution is to concatenate manually the arguments to a command in every place like that: std::string message = "PRIVMSG " + channelName + " :" + text + "\r\n";
However, that is hardly an elegant solution because it exposes the message format to every place where a message is generated. Next step would be creating a message class and its methods addArgument and addLastArgument. Since we want to pass arguments of different types we should make these methods overloaded or as templates. In the end, the “user” code will look like that:
Message message; message.addArgument("PRIVMSG"); message.addArgument(channelName); message.addLastArgument(text);
This is already better from information hiding point of view, but too wordy. Therefore, we are using the third technique, which is simple to use, intuitive for programmers and has the performance of the first method. The solution is possible due to the latest additions to C++, namely variadic templates (since C++11). They allow creating functions with variable argument count, where the type of each argument can be any, and that have no overhead for processing arguments as an array like standard C function with variable arguments. They are also reliable. This is how the most important method, appendArgs, is implemented: template
Two versions of appendArgs are defined – one for more than argument and one with one. The first one calls itself recursively thus appending space- separated arguments to the message (the object itself of type std::string). The
63 last one finishes the recursion and handles the last argument differently. I will not disclose the entire class code, but the usage of such class looks like that:
Message message("PRIVMSG", channelName, text);
This allows specifying message arguments in the most intuitive for a programmer way – like specifying arguments for a function. It is also as effective as possible because the variadic template recursion will be unrolled in compile time. The application of industrial design principles to the code is not so straightforward. We have noticed that investigating the industrial design principles helped to create elegant solutions and the use of latest technology allowed significantly simplify the code. We are suggesting looking into software internal parts, as they would be external parts. The future software developers will become the users of all or some internal parts of the developed software. Therefore, by looking into software design from our suggested perspective, we want to highlight the importance of system maintainability. We are applying industrial design principles to software to simplify future developers’ and current systems users’ life.
5.4. Industrial Design Principles in the User Interface
In this sub-chapter, we describe how we applied each of the industrial design principles to Unibz chat system.
Table 6. Application of Industrial Design Principles to User Interface
# Industrial Application to Unibz Chat System Design (UI and a Product) Principle 1 Accurate We tried to reach accuracy in our chat system by thinking about expected system functions from users’ point of view. To press a button “Get in” – user enters a chat. To press on a room name – user enters this room. To press a name on entered rooms panel – room becomes active. To click on other user nickname – small window with additional functions appears. To click on his own nickname – changing nickname window appears 2 Adequate price The chat is easily accessible for everybody and free of charge
64 # Industrial Application to Unibz Chat System Design (UI and a Product) Principle 3 Aesthetic Intuitive, simple and user-friendly user interface. We tried to make beautiful the overall UI design making buttons, textboxes, and panels in different size and colors 4 Appropriate We have redesigned KiwiIRC web client. shape Therefore, we have followed the predefined authors’ standard design 5 Attractive We made UI design similar to the main university web page design, which is already familiar to the most users 6 Branded ‘Unibz Chat’ is a new brand of the Free University of Bolzano chat systems. 7 Environmentally For the UI implementation were used only friendly pure JavaScript, CSS and html and no java, flash Silverlight or other web client technologies, that used many resources, such as battery and CPU. 8 Ergonomic We tried to make a comfortable, simple, user- friendly interface by selecting suitable colors, their transparent gradient and objects shape. 9 Evolutional UI of the web client is created by using latest technology, such as html5, JavaScript, CSS3 and SCSS 10 Functional The chat system delivers the proposed functionality to the users. If the user sends a message in the room, everyone presented in this room can see this message. If the user enters a room, this entered room is on the panel of his entered rooms. If the user selects “Ignore” someone, he will not see any more someone’s messages 11 Honest All the chat functionalities are shown to the user and described in user manual. There are unreal promises about the chat system 12 Innovative Unibz chat system is new communication tool for university community. Any chat system does not exist before in our university 13 Long lasting Our goal is not only to deliver what users want, but also to do it for a long period; therefore, we have made maintainable chat system 14 Market Chat system is easy introducible to the placement market, because it fulfills users’ demands and
65 # Industrial Application to Unibz Chat System Design (UI and a Product) Principle university currently has no analogous communication tool. 15 Optimal shape We have minimized everything in UI by removing all useless components and functionalities. 16 Safe Every message from one user to another is completely private; nobody else could see users’ messages. Chat system is not making any dangerous for health sounds. All sent messages are delivered as they were sent. No additional information is added, changed or removed. 17 Simple / Pure Simple and not complicated UI 18 Understandable UI is intuitive and functionality is predictable 19 Unobtrusive UI is not overflowed with useless functionalities, only the current needed functionalities are visible to the user. For example, to enter a chat, the user sees only the textbox to enter a nickname. Functions, such as “send private message” or “ignore”, are visible only after clicking on nickname. Exit functions are invisible, user can leave chat by closing browsers tab, typing command ‘/quit’ or closing active chat rooms 20 Usable/ useful UI is designed in such a way, that user can easily learn how to use the chat system. Users can freely interact with each other without any systems distraction. The chat system is an example of centralized communication way among university members. The university has not had such system yet; therefore, we believe that this chat system is going to be used.
In this sub-chapter, we have described the application of industrial design principles to chat system UI and the software product. UI has a visible connection with standard objects and usually the same simple users. Therefore, the application of industrial design principles to UI is easier and more intuitive compared to the source code application.
66 6. Conclusions
In this study, we are not evaluating the Unibz chat system itself, but the potential application of industrial design principles to software design. We have discovered the merging points between principles from physical and virtual worlds. It seems as bridging the gulf between two worlds. The interpretations of industrial design principles were adapted to software in order to discover their potential application. Industrial design principles are simple as they are formulated in everyday language, therefore programmers do not need to have any specific knowledge for understanding them. To find the possible application of industrial design principles we have interviewed an expert of software engineering. The expert helped us to find out the application areas of these principles and their application domains. This information helped us to transfer principles from physical world to software world by applying them to user interface and code design. As a result, with the application of industrial design principles, we have made a systems prototype with simple and understandable external user interface and internal code design. We have used the latest technology in chat system implementation – C++11, in order to simplify the code, its size and to make easier the systems maintainability. The working chat system prototype is now accessible from ‘http://chat.inf.unibz.it’. It will be proposed for use in September 2014, maintained and extended in some next years. Future chat changes will be done according to given users’ critics, comments and feedbacks. Interpretation of industrial principles and its potential application in software have been required more creativity, because they are simple and not so straightforward corresponded to software principles. Although, as said Ruben Verborgh38 “Programming is an art and therefore, we [...] are functional artists. We have a functional task as well as the duty to write beautiful code, because it is effective and thus lasts”. Because of close relationship and intersection between industrial design and software design principles, the application of the first one has made positive impact on the quality of our chat system and developed chat system prototype making it functional, understandable and simple. The Unibz chat was created to help students for academic purposes first of all and to centralize the communication between all university community. Its virtual nature can also encourage new students to be connected with the university community, feel more comfortable. It provides valuable opportunities for the new students to ask questions and listen to the experiences of senior students. Unibz chat combines three modern world
38 http://ruben.verborgh.org/blog/2013/02/21/programming-is-an-art/
67 initiatives on innovation, education and the digital society. It is a solution to improve the results of higher education system and the international attractiveness of the Free University of Bolzano. Smart growth of youth society requires accelerating the implementation of innovative internet projects and a range of 'high-tech' tools. The Unibz chat is one of such tools and has much potential for future exploration.
6.1. Answers to the Research Questions
The main research question of this study is: How can the industrial design principles be useful for software design and development? To answer this question we have investigated industrial design principles in chapter 2 and software design principles in chapter 3. In order to discover the potential application of industrial design principles in software we have identified a link between software and industrial design in chapter 4. Interview with an expert of software engineering field helped us to identify the software spheres where industrial design principles could be useful. In chapter 4.4 we have described practical application of the theoretical knowledge of our research about chat system development. As a result, we have developed prototype of the chat system for the Free University of Bolzano. It is functional, simple and requires minimal effort and maintenance support. Therefore, we can say quite successfully interpreted and applied industrial design principles to software. Although, the current chat system is only the prototype and it needs continue development by improving existence functionalities and adding new ones.
Supporting research questions are sub-questions of the main research question. Therefore, answering to these questions we can combine the answers with the answer to the main research question of our study.
The first supporting research question was: What are the differences and the similarities in industrial design and SW design principles? The answer to this question is presented in chapters 4 and 4.4. In chapter 4 we have defined model of potential application the industrial design principles to software. The concrete software areas of application for the principles are presented in Table 3. Potential Application of Industrial Design Principles in Software, where each industrial principle is analyzed regarding to the application in software domain.
The second supporting research question was: What are the industrial design role, impact and importance to software quality? In our study we have defined, that a software system is developed to be used by regular people, as an every physical object. Therefore, the industrial design guidelines can be applied to software to raise software quality. The developers are the experts of the code; they have differed understanding and point of view to the software program unlike regular people. Therefore, after our practical appliance shown in chapter 4.4, we can confirm that the system, which is developed not only upon the intuition of software developers, becomes user friendly, understandable and simple.
68 The third research question was: “How can we apply industrial design principles in software? The answers to this question can be found in sub- chapters 5.2 Industrial Design Principles in the Documentation, 5.3 Industrial Design Principles in the Source Code, and 5.4 Industrial Design Principles in the User Interface, where we in detail have described how we interpreted and applied industrial design principles to documentation, source code, user interface and the whole product.
The last research question was : What is the relationship between the exterior industrial design of physical objects and exterior user interface design and interior software system design? These relationships are described in chapter 4, where we have discovered the existence of visible relationship between physical objects and User interface and invisible relationship between system source code and physical objects. The first relationship is visible, because the users are the same: system and physical objects. Hidden relationship was discovered if we considered the developers as users’ of the code and a code itself as the object, which they are going to use. Looking from this perspective, we can apply the industrial design principles in software to improve code quality.
6.2. Future Research
Future research may be advanced by revealing new spheres of the application of industrial design principles to software design. New cases of potential applications to different software areas may be discovered. The study about relationships between mobile quality characteristics and industrial design principles may uncover new quality attributes of mobile applications, since we have already detected the direct overlapping between industrial design principles and mobile apps quality characteristics. We have noticed that different industrial design principles could correspond to the same software principles. This correspondence depends on the domain to which we are applying industrial design principles. The same principles are differently interpreted from Internal and external system views. Therefore, the separate models for different application domains can be find out. We propose to apply the model of this study to perform development of other software systems. We also suggest comparing and evaluating two development strategies, to achieve best results. The first software development can be performed with applying the industrial design principles in software and the second one can be done the same team or programmer without following the industrial design guidelines. Our proposed strategy needs more research and practical applications.
69 7. References
[1] D. Graziotin, The Impact of Affective States on Skills and Productivity in Software Development, Bolzano, 2012, p. 10. [2] K. M. Yirsaw Ayalew, "An Assessment of Changeability of Open Source Software," Computer and Information Science, vol. 6, no. 3, 23 May 2013. [3] H. Rombach, "Design measurement: Some Lessons Learned," IEEE Software, vol. 7, no. 2, pp. 17-25, 1990. [4] H. Zhu, Software Design Methodology, Butterworth-Heinemann, 2005. [5] C. T. Leondes, Intelligent Systems: Technology and Applications, 1 ed., vol. 6, Mishawaka: CRC Press, 2002. [6] M. Erlhoff, Kopfu ber zu Fu ßen. Prolog fu r Animateure, vol. 1, Kassel, 1987. [7] J. d. Noblet, Industrial Design, Paris: A.F.A.A, 1993. [8] A. P. G. T. Bruno Munari, Disegno & Design, 10 ed., Bergamo: Istituto Italiano Edizioni Atlas, 2003, p. 320. [9] B. E. Bu rdek, Design: Geschichte, Theorie und Praxis der Produktgestaltung, 1st ed., Ko ln: DuMont Buchverlag, 1991. [10] P. S. &. S. D. I. edg designlab Ltd, "PRODUCT DESIGN & INNOVATION," [Online]. Available: http://www.ait.gr/ait_web_site/pdfs_downloads/Session_3_pdf/ S3_P3_Didaskalou_DesignLab.pdf. [Accessed 25 04 2014]. [11] A. Ventura, "VENTURA ENCYCLOPEDIA for the ETHICAL and SUSTAINABLE Project," Free University of Bolzano-Bozen / Italy, 2013. [Online]. Available: http://venturaencyclopedia.it. [Accessed 09 04 2014]. [12] D. G. R. Carugati, Interior Design: Oggetti e protagonisti, A. M. E. S.p.A., Ed., Milano, 2005, p. 216. [13] T. B. E. W. M. Bernard I. Witt, Software Architecture and Design - Principles, Models and Methods, New York: Van Nostrand Reinhold, 1994. [14] D. M. W. David L. Parnas, "Active design reviews: principles and practices," ICSE '85 Proceedings of the 8th international conference on Software engineering, pp. 132-136, 1985. [15] R. C. Martin, Design Principles and Design Patterns, 2000. [16] K. B. J. B. W. O. D. R. Martin Fowler, Refactoring: Improving the Design of Existing Code, 1st ed., Addison-Wesley Professional, 1999.
70 [17] "Software Engineering," Information Processing, no. 71, pp. 530-538, 1972. [18] M. P. &. P. Team, Microsoft® Application Architecture Guide, 2nd ed., Microsoft Press, 2009. [19] D. Stro m, "Purposes of Software Architecture Design," Ronneby, 2005. [20] D. W. Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall, 2008. [21] D. T. Andrew Hunt, The Pragmatic Programmer: From Journeyman to Master, 1st ed., Addison Wesley, 1999. [22] S. Krug, Don't Make Me Think, 3rd ed., New Riders, 2003. [23] Y. H., "General design theory and a CAD system," in Proceedings of the IFIP WG5.2-5.3 Working Conference, Tokyo, Japan, 1980. [24] Y. K. Makoto Kikuchi, Abstract design theory, London, United Kingdom: Annals of the Japan, 2001. [25] P. C. L. B. Rick Kazman, "Classifying architectural elements as a foundation for mechanism matching," in Computer Software and Applications Conference, Washington, DC, 1997. [26] M. M. B. a. C. Scaffidi, "End-User Development," in The Encyclopedia of Human-Computer Interaction, 2nd ed., M. a. D. R. F. Soegaard, Ed., Aarhus, Denmark, 2013. [27] A. S. S. Luis Corral, "Defining Relevant Software Quality Characteristics from Publishing Policies of Mobile App Stores," in Proceedings of the 11th International Conference on Mobile Web Information Systems (MobiWIS 2014), 2014. [28] M. Ayers, "Book Review: Bringing Design to Software," ACM SIGSOFT Software Engineering Notes, vol. 21, no. 4, pp. 95 - 96, 01 07 1996. [29] M. D. d. e. d. R. O. M. U. Q. C. K. H. Ajrnal Chaumun, R. Keller, F. Lustman and G. Saint-Denis, "Design properties and object-oriented software changeability," Software Maintenance and Reengineering, 2000. Proceedings of the Fourth European, pp. 45-54, February 2000. [30] S. e. al, "ISO/IEC 9126 and 14598 integration aspects: A Brazilian viewpoint. The Second World Congress on Software Quality," Yokohama, Japan, 2000. [31] C. Alexander, Notes on the Synthesis of Form, Harvard University Press, 1964. [32] P. Y. Papalambros, "Design analysis and synthesis," The ASME Journal of Mechanical Design, vol. 130, no. 3, 2008. [33] "The Top 10 Elements of Good Software Design," [Online]. Available: http://www.clubofamsterdam.com/content.asp?contentid=545. [Accessed 28 03 2014].
71 Appendix
A. User stories
User stories captures what a chat participant can do in our chat system. We decided to use the traditional user-story template developed by ‘Connextra’39, which has a format: "As a
Story Card Enter Chat 1
As a guest, I want to enter chat, so that I can become chat participant of common university room, only by typing my nickname.
Jevgenija 20/11/2013 30h
Story Card Enter a Room 2
As a chat participant, I want to enter any university chat room by typing a command’ /join #[room]’ or by selecting a room from the predefined list of chat rooms, so that I can easily enter in any university chat room. Note: Entered room is active until participant has not entered in other room.
Jevgenija 11/20/2013 10h
39 http://agilecoach.typepad.com/photos/connextra_user_story_2001/ connextrastorycard.html 40 http://en.wikipedia.org/wiki/User_story
72 Story Card Select Active Room 3
As a chat participant, I want to select any active room from the list of entered rooms, so that I can see all rooms’ participants and messages, write my messages in this room, start private chat with any room participant and leave selected room. Note: Private active room is selected in the same way as any other room.
Jevgenija 11/21/2013 6h
Story Card Write a Message in a Room 4
As a chat participant, I want to write a message in any selected active room (including private rooms) so that I can be sure that anyone to whom I am writing will receive my message.
Jevgenija 11/21/2013 35h
Story Card See Messages in a Room 5
As a chat participant, I want to see all messages in selected active room, so that I can immediately write an answer.
Jevgenija 11/23/2013 20h
Story Card Start Private Chat with 6 another Participant
As a chat participant, I want to start private chat with any other participant in selected active room, so that I can immediately send and receive messages. Note: any participant can be invited to private chat by other participant
Jevgenija 11/23/2013 15h
73 Story Card See List of Room 7 Participants As a chat participant, I want to see the list of all active room participants, so that I can start a private chat with other participant or write a message in common chat to any participant
Jevgenij 11/23/2013 4h a
Story Card Be Invited to Private Chat 8 by Other Participant
As a chat participant, I want be invited to private chat by other participant, so that I can be always sure, that I have received all private messages. Note: When one participant is sending a private message to other participant, new private room is automatically created.
Jevgenija 11/23/2013 8h
Story Card See List of Entered Rooms 9
As a chat participant, I want to see the list of all entered rooms, so that I can easily select an active room.
Note: Private rooms are considered as entered rooms and are shown in the same list
Jevgenija 11/20/2013 8h
Story Card See List of Available 10 Rooms
As a chat participant, I want to see a list of all available rooms, so that I can easily choose a room to enter.
Jevgenija 11/20/2013 15h
74 Story Card Leave a Room 11
As a chat participant, I want to leave any selected active room by closing room window or by typing a command ‘/part’, so that I will not be present anymore in this room.
Jevgenija 11/20/2013 5h
Story Card Leave Chat 12
As a chat participant, I want to leave the chat whenever I want by closing chat window, so that I can quickly exit chat without thinking how to do it.
Jevgenija 11/20/2013 2h
B. User Manual
Go to
‘chat.inf.unibz.it’
Enter your nicknameGo to ‘chat.inf.unibz.it’
75 Enter your nickname
Click ‘Get in’
Click on room to start chatting
Click on room name to enter
Click on your nickname to change it
76 Write new room topic
Write message
or command
Write message
or command
To start private conversation: click on nickname and on ‘Message’
To ignore messages from a person: click on nickname and check “Ignore”
Commands
For faster communication, you can type commands into the message textbox COMMAND MEANING EXAMPLE /join [roomname] Enter a room /join E331 /nick [yournewnickname] Change your nick /nick PETER /part Leave a room /part /list See list of rooms /list /quit Exit a chat /quit
77