< PreviousChapter 1: Introduction20Chapter Contents1.1 Motivation for Doctorate ................................................... 211.1.1 Rich-Client Era ........................................................ 211.1.2 HTML5 Single-Page-App (SPA) Approach ........................ 221.1.3 Library and Framework Landscape ............................... 231.1.4 Mastering Complexity, Scalability and Integration ............. 231.1.5 Foundational User Interface Architecture ........................ 241.2 Contributions of Doctorate ................................................. 251.2.1 Scientific Contributions ............................................. 251.2.2 Technological Contributions ....................................... 261.3 Structural Overview of Dissertation ...................................... 281.4 Typographical Conventions of Dissertation ............................ 30Motivation for Doctorate211.1 Motivation for DoctorateThe main challenge for software architects is: there are different ways to design a good software architecture, but there are infinite ways to create a bad one. — Prof. Michael Stal 1.1.1 Rich-Client EraThe software development industry, in the context of User Interfaces (UI), already multiple times went through a so-called “pig cycle”: switching back and forth be-tween Fat-Client, Rich-Client and Thin-Client architectures, each time triggered by a particular major new possibility (see Figure 1.1 on page 21).The last switch was mainly triggered during the years 2005 to 2009 by the new possibilities of rich interactions, like gestures and voice, plus mobile devices, like smart-phones and tablets. Since at least 2010, the industry now is in a UI era clearly dominated by the Rich-Client architecture.Nowadays, UIs of applications are implemented by dedicated frontend pro-grams, which fully autonomously render and drive the entire UI of the application — including all dialog mask renderings, dialog interactions, and dialog transitions. They connect over the network to one or more backends for bare domain data communication only (see Figure 1.2 on page 22).There are two popular deployment variants of this approach: in the “offline” variation, the frontend program is in advance and permanently deployed onto a client; in the “on-the-fly” variation, the frontend program is deployed onto a server and just on-demand loaded into the client.Figure 1.1: “pig cycle” of User Interface architecturesArchitecture19751980198519901995200020052010201520202025Thin-ClientRich-ClientFat-ClientX11Win 3.1CGIJSFTODAY3270GraphicalUser InterfacesEasyDeploymentRichInteractionsMobileDevicesMassiveBandwidth?FlexChapter 1: Introduction22The advantages of the Rich-Client UI approach are the possibility for pleasant visualizations, rich interactions, and high responsiveness. As a consequence, these UIs can provide an excellent User Experience (UX) and hence are nowadays force-fully requested by users in both the consumer and enterprise markets.1.1.2 HTML5 Single-Page-App (SPA) ApproachMultiple technology stacks currently exist for implementing Rich-Client based User Interfaces (UI): Adobe Flash/Flex, ORACLE JavaFX, Eclipse RCP, Cap’n Proto, Google GWT, Vaadin, or W3C HTML5. However, since about ten years, only one of those technologies greatly outperforms all others, both in flexibility, powerfulness, adop-tion count and popularity: W3C HTML5 [Faulkner et al. 2017]. This is the standard-ized technology stack consisting of the popular Web technologies DOM, HTML, MathML, SVG, WebGL, PNG, WOFF, CSS, JavaScript, and much more.Instead of just using W3C HTML5 for Web sites (and this way effectively follow-ing a Thin-Client architecture), when using W3C HTML5 for implementing Rich-Cli-ent based User Interfaces of applications, we are talking about so-called HTML5 Single-Page-Apps (SPA). Here, instead of requesting multiple Web pages, and this way sending individual masks from the server to the client (the bare Web browser), only a single Web “page” is requested. This “page” contains just a (large) JavaScript program, which in turn renders the entire UI fully autonomously within the client into the DOM by using the mentioned Web technologies.Thin-Client ArchitectureRich-Client Architecture(offline deployment)Standalone ApplicationArchitectureServerClientView MaskView MaskView MaskBackend CodeFrontend CodeView MaskFrontend CodeView MaskmakemakemaketransmitRich-Client Architecture(on-the-fly deployment)View MaskView MaskFrontend CodemaketransmitBackend CodeBackend CodeFrontend CodeFrontend CodeBackend Codesend /receivesend /receivesend /receivesend /receiveFigure 1.2: Different User Interface architecturesMotivation for Doctorate231.1.3 Library and Framework LandscapeThe W3C HTML5 Web technology standards are rather low-level, focusing primarily on the bare rendering and manipulation of information in the Document Object Model (DOM) [Wilson et al. 2000] of the Web browser. However, there is no support for how this rendering and manipulation of information is orchestrated on an ap-plication level.Hence, since the early days of the Web in the 1990th, Open Source libraries and frameworks regularly spring up on a quarterly basis, each one trying to fill a gap on the higher-level. So, a typical abstract Functional View of an HTML5 SPA looks like Figure 1.3 on page 23. Unfortunately, often the many libraries and frameworks are not directly com-patible with each other. Especially the large frameworks like Angular [Google 2010], Aurelia [Eisenberg et al. 2014], EmberJS [Katz et al. 2011] or ExtJS [Sencha 2007], by definition of a framework, do not interplay nicely with foreign libraries or even oth-er frameworks, of course.In other words: the last two decades brought up a myriad of solutions, but ei-ther one has just to stick with a single “all-in-one“ framework and accept its captive scope, or one has to investigate into the integration of dozens of partial solutions. Unfortunately, experience shows that the individual customer requirements in at least the Custom Software Development (CSD) field nearly always demand the latter1.1.4 Mastering Complexity, Scalability and IntegrationFor two decades, the W3C HTML5 Web technologies and the related Open Source libraries and frameworks still progress at an extremely high invention rate. Hence, the Rich-Client based User Interface (UI) approach of HTML5 Single-Page-Apps has Figure 1.3: HTML5 SPA Technology Stack OverviewComponentJS, VueJS, …Native CodeOperating System (OS)Web TechnologyRun-Time (RT)W3C HTML5 StandardsLibraryLibraryLibraryLibraryFrameworkFrameworkSingle-Page Application (SPA)JavaScript CodejQuery, I18Next, Bootstrap,HammerJS, MouseTrap, …DOM, HTML, MathML, SVG,PNG, OTF/TTF, CSS, …Chrome, Firefox, Safari, Edge,Opera, Electron, NW.js, CordovaWindows, macOS, GNU/LinuxChapter 1: Introduction24its price. Its great flexibility and power come with the following four challenging Primary Architecture Requirements (PAR) in practice: ■[PAR1] Frontend Complexity: an inherent high overall frontend complexity, due to the many involved standards and technologies. ■[PAR2] Dialog Scalability: a lack of native support for true scalability be-yond a handful of dialogs, because most existing Web technologies focus on individual Web pages of Web sites instead of full-blown UIs of HTML5 SPAs. ■[PAR3] Solution Integration: a very high integration necessity, due to the partial solutions of the many libraries and frameworks, which have to be forced to interplay with each other. ■[PAR4] Moving Target: a burden of having to target a continuously chang-ing technology stack, although the solution has to last for usually five or more years.We are faced with this nasty situation for a long time now. It is rather harmless for small UIs, consisting of just a handful dialogs and having to last for just about one or two years. There one can just choose a large “all-in-one” framework, and none of the above problems really bites one.However, the situation becomes a major hurdle for large UIs, consisting of a few hundred dialogs and having to last for many years. This is especially the case for the complex UIs of industrial Business Information Systems [Denert 1991], usually implemented in the Custom Software Development (CSD) field [Siedersleben 2002] [Siedersleben 2003] [Siedersleben 2004]. Here, mastering the above four major challenges is inevitable.1.1.5 Foundational User Interface ArchitectureSoftware Engineering experience over the last decades indicates that to survive in such a situation, instead of paying attention to the continual coming and going of particular technology standards and related Open Source libraries and frame-works, we better should: ■Find a flexible UI architecture of well-proven basic concepts and support-ing methods to have a solid foundation for mastering complexity and scal-ability. This tackles [PAR1] and [PAR2] above. ■Find a suitable technology stack approach to loosely and regularly (re-)integrate the existing libraries and frameworks. This tackles [PAR3] and [PAR4] above.To find such a foundational User Interface architecture and related HTML5 Single-Page-App technology stack approach was the ultimate goal and motivation for this doctorate.Contributions of Doctorate251.2 Contributions of DoctorateYou must be the change you wish to see in the world. — Mahatma Gandhi (1869–1948)This doctorate and dissertation deliver multiple scientific and technological con-tributions to state of the art in Computer Science and Software Engineering and the software technology world of Open Source and the Custom Software Development discipline.1.2.1 Scientific ContributionsThis dissertation delivers the following 12 particular scientific contributions on the theory side: ■[SC01] User Interface Aspects: the unique conceptual aspect every User Interface technology has to cover (see section 6.2 on page 116). ■[SC02] User Interface Ontology: the taxonomy and relationships of User Interface related artifacts, plus the interplay between the Requirements En-gineering and Software Development disciplines in this context (see section 6.3 on page 119 and [Grewenig 2014] and [Engelschall 2013c]). ■[SC03] Hierarchical Composition: the approach of optically decomposing a User Interface into a hierarchy of distinguished dialogs during planning-time and then (re-)composing the User Interface out of the component tree of dialogs under run-time (see section 6.4 on page 122 and [Engels-chall 2013c]) ■[SC04] Component Tree State Transitions: the state-based life-cycle of components and the invariant-preserving state transitions of the Compo-nent Tree (see section 6.5 on page 126). ■[SC05] Component Tree Unified Communication: the unified hierarchical communication on a Component Tree with the help of Events, Services, Models, and Hooks (see section 6.6 on page 135). ■[SC06] User Interface Fragment Sockets: the physical integration of User Interface fragments with the help of hierarchically linked sockets and the relationship to the optical layout of those User Interface fragments (see section 6.7 on page 147). ■[SC07] Model-View-Controller/Component-Tree (MVC/CT) Pattern: the var-iation of the classic Model-View-Controller (MVC) pattern for implementing dialogs as triads of role-based components on a Component Tree (CT) (see section 6.8 on page 150) [Engelschall 2014b] [Engelschall 2014c].Chapter 1: Introduction26 ■[SC08] Component Tree Pattern Catalog: the recurring patterns of Model, View and Controller components on a Component Tree (see section 6.11 on page 173, section 6.12 on page 176 and [Vaas 2014]). ■[SC09] Hierarchical Data Binding: the variation of Data Binding for bidirec-tionally binding View Masks to a hierarchy of Presentation Models (see sec-tion 6.9 on page 164 and [Rummel 2014]). ■[SC10] Real-Time Component Tree Visualization: the real-time visualization of the Component Tree behind the User Interface for seeing component structure, states and roles under run-time (see section 6.13 on page 179). ■[SC11] Real-Time Component Tree Tracing: the real-time tracing of the Component Tree behind the User Interface for seeing component commu-nication under run-time (see section 6.13 on page 179 and [Vaas 2014]). ■[SC12] Hierarchical User Interface Component Architecture (HUICA): the overall User Interface architecture, combining all of the above aspects (see section 6.1 on page 115).All scientific contributions are available to everyone under the Creative Commons Attribution-NoDerivatives 4.0 International (CC BY-ND 4.0) distribution license. 1.2.2 Technological ContributionsAdditionally, this doctorate delivers the following 13 particular major technologi-cal contributions on the practical side (not mentioning the numerous minor tech-nological contributions which were necessary as the underlying dependencies): ■[TC01] Component-Orientation Framework ComponentJS: the JavaScript framework for implementing Component-Orientation, Hierarchical Com-position [SC03], Component Tree State Transitions [SC04], Component Tree Unified Communication [SC05] and User Interface Fragment Sockets [SC06] (see [Engelschall 2009a]). ■[TC02] Role-Library ComponentJS MVC: the OOP add-on library to Compo-nentJS for the abstract classes of Model, View, and Controller component roles of the Model-View-Controller/Component-Tree (MVC/CT) Pattern [SC07] (see [Engelschall 2016c]). ■[TC03] ComponentJS VueJS Plugin: the implementation of the Hierarchical Data Binding [SC09] by gluing the View Mask rendering and Data Binding library VueJS to the Presentation Model hierarchy of ComponentJS (see [En-gelschall 2016d]). ■[TC04] ComponentJS Debugger: the implementation of the Real-Time Component Tree Visualization [SC10] functionality to monitor the struc-ture and states of the User Interface implementation under run-time (see [Engelschall 2011]).Contributions of Doctorate27 ■[TC05] ComponentJS Tracing: the implementation of the Real-Time Com-ponent Tree Tracing [SC11] functionality to monitor the communication of the User Interface implementation under run-time (see [Engelschall & Vaas 2013]). ■[TC06] VueJS I18Next: the VueJS extension plugin for providing integration with the Internationalization (I18N) library I18Next to allow the User Inter-face to seamless switch the language under run-time (see [Engelschall 2016a]). ■[TC07] jQuery Markup: the jQuery extension plugin for loading template based View Masks (see [Engelschall 2013B]). ■[TC08] jQuery Stage: the jQuery extension plugin for determining Viewport information (see [Engelschall 2013A]). ■[TC09] jQuery Page: the jQuery extension plugin for switching between multiple optical pages with animated transitions (see [Engelschall 2016b]). ■[TC10] Style-Scope: the PostCSS and PostHTML plugins for locally scoping Cascading-Style-Sheets (CSS) (see [Engelschall 2017a]). ■[TC11] TypoPRO: the curated collection of free fonts for professional typog-raphy in HTML5 Single-Page-Applications (see [Engelschall 2014A]). ■[TC12] GemstoneJS: the master framework based on ComponentJS and corresponding jQuery and VueJS plugins to cover all the required User In-terface Aspects [SC01] (see [Engelschall 2016e]). ■[TC13] GraphQL-IO: the GraphQL and WebSocket based framework for in-tegrating HTML5 frontend and Node.js backend (see [Engelschall 2017b]).All technological contributions are available, without exception, to everyone under liberal Open Source software distribution licenses which allow both non-commer-cial and commercial usage. For background on Open Source software see [Phipps 2012].Chapter 1: Introduction281.3 Structural Overview of DissertationIf you cannot grok the overall structure of a program while taking a shower, you are not ready to code it. — Richard E. PattisThis dissertation is split into a prolog, eleven distinct chapters, and an epilog — all mapped onto five logical parts. Each chapter is divided into individual sections, each one optionally also divided into subsections. Each chapter starts with an ex-cerpt of the global Table of Contents. The dissertation outline follows as a brief over-view.Part I:Prolog and IntroductionPrologCover, Meta-Information, Dedication, Abstract, Acknowledgements, and Table of Contents.Chapter 1:IntroductionMotivation and timeline of the doctorate, followed by a summary of the contribution of the dissertation, plus this content over-view of the dissertation.Part II:Foundations and ContextChapter 2:FoundationsIntroduction of the foundational subjects User Interface, Dialog, Component, Model, State, and Life-Cycle.Chapter 3:ContextClarification of the contextual subjects Ap-plication User Interface, Rich-Client Archi-tecture, Web Technologies, HTML5 Single-Page-App.Part III:Requirements, State of the Art and SolutionChapter 4:RequirementsDetermination of the known requirements and new challenges in the context of Rich-Client based User Interface development.Chapter 5:State of the Art:Related Work in Ar-chitectures, Patterns and FrameworksChecking of the state of the art and gaps in related work in Component Architectures, Model-View Separation Patterns, and Web Technology Framework Approaches.Chapter 6:Solution: Hierarchical User Interface Component Architecture (HUICA) Delivery of the contributions forming the Hi-erarchical User Interface Component Archi-tecture (HUICA) at the User Interface Level, Component Tree Level, and Component Level.Structural Overview of Dissertation29Part IV:Implementa-tion, Example, Experience and EvaluationChapter 7:Implementation: Libraries and Frame-works Implementation of a technology platform, stack and environment for using the Hierar-chical User Interface Component Architec-ture (HUICA) in practice, based on run-time frameworks and libraries, and companion build-time tools.Chapter 8:Example:HUICA in Demonstra-tion EnvironmentDemonstration of the Hierarchical User In-terface Component Architecture (HUICA) in a small context of a simple example applica-tion.Chapter 9:Experience:HUICA in Industrial PracticeExperiences and Lessons Learned with the Hierarchical User Interface Component Ar-chitecture (HUICA) in large contexts of non-trivial industrial Mobile Applications, Techni-cal Applications, and Business Information Systems.Chapter 10: Evaluation: Facing Requirements and ChallengesEvaluation of the determined requirements and challenges through interviews of indus-try experts.Part V:Conclusion and EpilogChapter 11:ConclusionConclusion by highlighting the Reached Goals and Lessons Learned and finishing with Future Prospects.EpilogReferences, About Book and Backcover.If one is already familiar with User Interfaces, HTML5 Single-Page-Apps and the pop-ular Open Source libraries and frameworks, one can directly jump into Chapter 6 and 8 and just find out about the Hierarchical User Interface Component Architec-ture (HUICA) at both the conceptual and practical side.Next >