< PreviousChapter 9: Experience270Figure 9.17: User Interface (frame and app) of Insurance Suite (Außenregulierung)Figure 9.18: Component Trees (frame and app) of Insurance Suite (Außenregulierung)Mobile Applications271instantiated on every Web page load operation. The result is an optically and logi-cally seamless total UI.9.2.4 Vote (2016)Vote is a training support application for online polling and voting, developed by msg Applied Technology Research in 2016. It targets the smartphone class of mobile devices. Its Technology Stack, on the Front-End side, is primarily based on Twitter Figure 9.19: User Interface of VoteChapter 9: Experience272Bootstrap, VueJS, ComponentJS, and Apollo Client, and on the Back-End side, it is primarily based on Mikrokernel, HAPI, GraphQL, and Node.js.The Vote UI (see Figure 9.19 on page 271) source code consists of 19 UI Frag-ments, 63 UI Components and 6,000 Lines of Code. During run time the Component Tree (see Figure 9.20 on page 272) consists of 73 instantiated Components.There were three lessons learned from Vote: First, to achieve the usual page transitions on swipe gestures users are used to on mobile devices, a jQuery plugin jQuery Page was developed, integrated into the canvas View Component and linked to the Component Tree communication through events. This proved that HUICA plays well even with very central foreign UI management mechanisms.Second, Vote was the first HUICA application for the use of VueJS and Com-ponentJS together, to have a declarative Data Binding available and this way dra-matically reducing the necessary “boilerplate” code in the View Components. The developers very much appreciated this important improvement.Third, Vote was also the first HUICA application where GraphQL was introduced for a declarative and query-based Back-End communication. The Presentation Mod-el in the Model Components acts as the glue code between the VueJS and GraphQL Data Binding.HUICA allows even the integration of central foreign UI management mechanisms like page transitions. Figure 9.20: Component Tree of VoteTechnical Applications2739.3 Technical ApplicationsExperience is not what happens to you, it is what you do with what happens to you. — Aldous HuxleyAlthough Business Information Systems were the primary target for HUICA, it was also applied to bare technical applications. At first, it looked that these are differ-ent, but experience showed the contrary. The lessons learned follow in this section.9.3.1 CloudTeX (2013)CloudTeX is a collaborative online LaTeX editor for teams of scientists, developed by CloudTeX UG in 2013. It is provided as a Software as a Service (SaaS). Its Technology Stack on the Front-End side is primarily based on ExtJS and ComponentJS.The CloudTeX UI (see Figure 9.21 on page 273) source code consists of about 10 UI Fragments, about 30 UI Components and a few thousand Lines of Code. During run time, the Component Tree consists of about 15 instantiated Components.The lessons learned from CloudTeX was that HUICA is not limited to traditional Business Information Systems and instead can be used just fine for bare technical applications. However, those applications, like CloudTeX, have a noticeably smaller number of UI Fragments and hence necessary UI Components.HUICA can be used also for bare technical appli-cations, although they usually have a noticable smaller number of UI Fragments.Figure 9.21: User Interface of CloudTeXChapter 9: Experience274Figure 9.22: User Interface of WebTVFigure 9.23: Component Tree of WebTVTechnical Applications2759.3.2 WebTV (2016)WebTV is a flexible image and video broadcasting platform, developed by Jochen Hörtreiter and Ralf E. Engelschall in 2016. It targets both TV, desktop, tablet and smartphone devices and can be used in both unattended broadcasting and at-tended interactive mode. Its Technology Stack, on the Front-End side, is primarily based on VueJS and ComponentJS, and on the Back-End side, it is primarily based on Mikrokernel, HAPI, and Node.js.The WebTV UI (see Figure 9.22 on page 274) source code consists of 5 UI Frag-ments, 15 UI Components and 3,300 Lines of Code. During run time, the Compo-nent Tree (see Figure 9.23 on page 274) consists of 17 instantiated Components.There were two lessons learned from WebTV: First, even small techni-cal applications can benefit from the structure applied by HUICA. Second, as the UI was first done with jQuery and later with VueJS, a migration to a declarative Data Binding even can be done through a refactoring with a reasonable amount of effort.9.3.3 DEXI (2017)DEXI (Digital EXcellence Index) is a small application for calculating the level of ma-turity in Digital Transformation, developed by Ralf S. Engelschall in 2017. It targets the desktop and tablet class of devices. Its Technology Stack on the Front-End side is primarily based on GemstoneJS, which in turn is based on VueJS and Compo-nentJS.The DEXI UI (see Figure 9.24 on page 276) source code consists of 2 UI Fragments, 3 UI Components and 530 Lines of Code. During run time the Component Tree (see Figure 9.25 on page 276) consists of 4 instanti-ated Components.DEXI arguably is one of the smallest HUICA applications, both from a Lines of Code and instantiated Components point of view. Nevertheless, it was the first ap-plication based on GemstoneJS, an “all-in-one” framework for HUICA. As such, DEXI provided much important feedback to adjust GemstoneJS to fit HUICA in practice.One can migrate from a manual to a declarative Data Binding through a harmless refactoring.With GemstoneJS an all-in-one framework for all aspects of HUICA exists.276Figure 9.24: User Interface of DEXIFigure 9.25: Component Tree of DEXIChapter 10EvaluationChapter 10: Evaluation278Chapter Contents10.1 Academic Evaluation ........................................................ 27910.1.1 Upstream Author Evaluation ....................................... 27910.1.2 Downstream Developer Evaluation ............................... 28410.2 Practical Feedback ........................................................... 28610.2.1 Imperative vs. Declarative Data Binding ......................... 28610.2.2 Reduced vs. Full-Blown MVC/CT Triads ........................... 28610.2.3 Explicit vs. Automatic Resource Allocation Spooling .......... 28710.2.4 Code-First vs. Contract-First Approach ........................... 28710.2.5 Natural vs. Traditional Component Tree Visualization .......... 288Academic Evaluation27910.1 Academic EvaluationExtraordinary claims require extraordinary evidence. — Carl SaganIn this section, the Hierarchical User Interface Component Architecture (HUICA) solution (see Chapter 6 on page 111) is evaluated from an academic perspective. For this, the solution is conceptually checked against the Requirement Suite (see Section 4.2 on page 61) by individual attainments for each requirement.10.1.1 Upstream Author EvaluationIn this subsection, the HUICA solution is evaluated from an academic “upstream” perspective of the HUICA author. The attainment evaluation of the Requirement Suite from the perspective of the author one can find summarized in Figure 10.1 on page 280. In general, as expected, all requirements are attained in a GOOD, VERY GOOD or even PERFECT way by HUICA. See Subsection 4.3.1 on page 67 for the applied Requirements Evaluation Scale. In detail, the attainment evaluation and rationale from an upstream author perspective and the corresponding solution references are: ■[REQ-F1] Complete User Interface Aspect Coverage: PERFECT. The ration-ale is that HUICA, by design, completely fulfills the requirement. See Sec-tion “6.2 User Interface Aspects” on page 116 for details. ■[REQ-F2] Complete User Interface Ontology: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. See Section “6.3 User Interface Ontology” on page 119 for details ■[REQ-F3] Separation of Mask, Style, and Behavior: PERFECT. The rationale is that HUICA, by design, completely fulfills the re-quirement. See Section “6.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)” on page 150 for de-tails. ■[REQ-F4] Separation of Controls, Interactions, and Events: PER-FECT. The rationale is HUICA, by design completely fulfills the re-quirement. See Section “6.8 Hierarchical Dialog Architecture: Model-View-Controller/Component-Tree (MVC/CT)” on page 150 and Section “6.9 Data Binding of Presentation Model” on page 164 for details. ■[REQ-F5] Dialog-Level Structuring: PERFECT. The rationale is that HUICA, by design, completely fulfills the requirement. See Section “6.4 Hierarchi-cal Component Structure” on page 122, Section “6.7 Hierarchical Dialog The Evaluation compares the Solution to the Re-quirements.Next >