< PreviousChapter 9: Experience260Figure 9.7: Component Tree of PSCFigure 9.6: User Interface of PSCBusiness Information Systems261and their underlying UI Components the parallel development went very smooth-ly. Also, the large Component Tree during run time caused no noticeable perfor-mance penalty for the application.9.1.4 KEZ-PSC (2014)KEZ-PSC (Kennzahlen, Planungs-Steuerungs-Cockpit) is a project management appli-cation, developed by msg systems in 2014 for an automotive OEM. Its Technology Stack, on the Front-End side, is primarily based on Twitter Bootstrap and Compo-nentJS, and on the Back-End side, it is primarily based on Java EE.The KEZ-PSC UI (see Figure 9.6 on page 260) source code consists of 160 UI Fragments, 480 UI Components and 57,900 Lines of Code. During run time the Com-ponent Tree (see Figure 9.7 on page 260) consists of between 300 and 700 instan-tiated Components.KEZ-PSC is one the largest Business Information Systems based on HUICA and so proved that HUICA scales well, both during development time and run time. However, most notably, its absolute killer feature is its built-in live printing functionality. One can choose to print a UI Di-alog, KEZ-PSC switches to a dedicated print preview screen, the user can still post-adjust the content directly on the print preview screen and finally print the content from there.The noticeable feature here is the post-adjustment functionality directly on the print preview screen! It is possible only thanks to HUICA: the print preview screen is actually based on the regular UI, just instantiated a second time into the Component Tree and switched into a slightly adjusted rendering optic with the help of dedicated print-styles. As the content on the print preview screen is actu-ally live UI Fragments as in the regular UI, the user can still adjust the entire content as usual. Currently, this killer feature has never been seen anywhere else. However, with HUICA it was achieved rather easily.9.1.5 MCT (2015)MCT is a small education support application for online running multiple flavors of Multiple-Choice-Tests in parallel to on-site training, developed by msg Applied Tech-nology Research in 2015. 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 Microkernel and Node.js.The MCT UI (see Figure 9.8 on page 262) source code consists of 7 UI Frag-ments, 21 UI Components and 2,100 Lines of Code. During run time the Component Tree (see Figure 9.9 on page 262) consists of 22 instantiated Components.The lessons learned from MCT is simple: manual Data Binding is cruel, even for very small applications. The first version of MCT used jQuery for rendering the UI HUICA allowed a print preview screen where the user can still post-adjust the content to be printed.Chapter 9: Experience262Figure 9.9: Component Tree of MCTFigure 9.8: User Interface of MCTBusiness Information Systems263Figure 9.10: User Interface of TechRADARFigure 9.11: Component Tree of TechRADARChapter 9: Experience264Fragments, and although MCT consists of just 21 UI Components, the resulting “boilerplate” code was a major maintenance problem. After a later refactoring, where jQuery and manual Data Binding were replaced with VueJS and declarative Data Binding, the code base became a lot easier to comprehend and maintain.A second lesson learned was that not every optical UI Fragment ac-tually has to be implemented with its dedicated UI Component Triad. The “questions” Component Triad of MCT actually renders an arbitrary amount of individual UI Fragments, one for each question and the cor-responding answers. This works, because there are only small structural differences between the individual MCT question types. The alternative would have been to instantiate a Component Triad for each individual UI Fragment. Both approaches are acceptable. The single Component Triad approach makes the state handling between questions simpler. The multiple Triad approach would make structurally totally different UI Fragment renderings for each question simpler.9.1.6 TechRADAR (2016)TechRADAR is an information retrieval application for IT trends, developed by msg Applied Technology Research in 2016. Its Technology Stack, on the Front-End side, is primarily based on Twitter Bootstrap, VueJS and ComponentJS, and on the Back-End side, it is primarily based on Sharepoint.The TechRADAR UI (see Figure 9.10 on page 263) source code consists of 5 UI Fragments, 12 UI Components and 3,100 Lines of Code. During run time the Com-ponent Tree (see Figure 9.11 on page 263) consists of 17 instantiated Compo-nents.The interesting aspect experienced from the development of TechRADAR was that the entry barrier for HUICA is a lot smaller than ex-pected by HUICA experts. An average experienced Web developer was able to comprehend HUICA and the underlying Technology Stack and develop the entire application within just four weeks. So, although HUICA is com-plex, it nevertheless has a reasonable small entry barrier in practice.9.1.7 CampS (2017)CampS is a prototypical university campus management system, developed by msg Applied Technology Research in 2017. It is the reference implementation of a Business Information System from vitruv, a book project on the topic of Software Architecture.Its Technology Stack, on the Front-End side, is primarily based on ElementUI, VueJS, ComponentJS and Apollo Client, and on the Back-End side, it is primarily based on Microkernel, HAPI, GraphQL, and Node.js.Multiple strongly related UI Fragments can be rendered with dedicated UI Component Triads or with a single master UI Component Triad.HUICA is complex, but nevertheless still has a reasonable small entry barrier in practice.Business Information Systems265The CampS UI (see Figure 9.12 on page 265) source code consists of 35 UI Fragments, 130 UI Components and 7,300 Lines of Code. During run time the Com-ponent Tree (see Figure 9.13 on page 266) consists of between 150 and nearly 1000 and more instantiated Components, because the CampS UI is tab-based and instantiates mostly the entire UI multiple times per tab.There are two lessons learned from CampS: First, because of the massive re-instantiation CampS proved once again that HUICA scales very well also during run time. Second, as VueJS is used for UI View Mask rendering and GraphQL is used for communication between the Front End and the Back End, CampS is a fine exam-Figure 9.12: User Interface of CampSChapter 9: Experience266ple of HUICA with two declarative Data Bindings playing together. The two Data Bindings are loosely coupled through the intermediate Presentation Model of the HUICA Model Components.Figure 9.13: Component Tree of CampSMobile Applications2679.2 Mobile ApplicationsExperience enables you to recognize a mistake when you make it again. — Franklin P. JonesEspecially in the years 2013 to 2016 the HTML5 SPA approach also for Mobile Appli-cations became rather popular. Hence, a few of them were also implemented with HUICA. The lessons learned follow in this section.9.2.1 JumbleBooth (2010)JumbleBooth is a shopping platform with an alternative User Interface for mobile devices, developed 2010 by OpenPKG GmbH. It targets the smartphone class of mo-bile devices. Its Technology Stack is primarily based on Sencha Touch, a variant of Sencha ExtJS for mobile devices, and ComponentJS.The JumbleBooth UI (see Figure 9.14 on page 267) source code consists of 5 UI Fragments, 15 UI Components and 1,400 Lines of Code. During run time, the Com-ponent Tree consists of 15 instantiated Components.Figure 9.14: User Interface of JumbleBoothChapter 9: Experience268Figure 9.15: User Interface of Architecture FundamentalsFigure 9.16: Component Tree of Architecture FundamentalsMobile Applications269JumbleBooth was the first application based on the initial ComponentJS and hence used just a very early and weak variant of HUICA. Nevertheless, it already showed that HUICA works with both the special “programming model” of Sencha Touch (where instead of HTML/CSS/JavaScript one just writes JavaScript) and scales down even for very small User Interfaces.9.2.2 Architecture Fundamentals (2013)Architecture Fundamentals is an information retrieval application for the content of a forthcoming book on fundamental software architecture aspects, developed in 2013 by the author of this dissertation. It targets the tablet class of mobile devices. Its Technology Stack is primarily based on jQuery and ComponentJS.The Architecture Fundamentals UI (see Figure 9.15 on page 268) source code consists of 10 UI Fragments, 29 UI Components and 1,600 Lines of Code. During run time, the Component Tree (see Figure 9.16 on page 268) consists of 29 instanti-ated Components. The lessons learned from the Architecture Fundamentals applica-tion was that HUICA and Responsive Design could be used together just fine. The application used Responsible Design in multiple View Compo-nents to adjust to the different viewport sizes of various tablets.9.2.3 Insurance Suite, Außenregulierung (2015)Insurance Suite (Außenregulierung) is an insurance field service support application, developed by innovas and msg systems in 2015. It targets the tablet class of mobile devices. Its Technology Stack is primarily based on Twitter Bootstrap, jQuery, and ComponentJS.The Insurance Suite (Außenregulierung) UI (see Figure 9.17 on page 270) source code consists of 21 UI Fragments, 85 UI Components and 20,400 Lines of Code. During run time, the Component Tree (see Figure 9.18 on page 270) consists of 65 instantiated Components.The lessons learned here was all about foreign UI integration. The re-quirement in Insurance Suite was to optically and logically integrate both multiple Rich-Client and HUICA-based UIs and multiple legacy Thin-Cli-ent and non-HUICA-based UIs into a single UI. To achieve this high goal, the approach chosen here was very unusual: an outer frame Rich-Client UI was developed with HUICA which orchestrates the different inner sub-UIs.The inner sub-UIs are then loaded into <iframe> containers and communi-cate with the outer frame UI through a common Inter-Process Communication (IPC) library. For the Rich-Client-based sub-UIs this IPC library is loaded and instantiated just once on startup. For the Thin-Client-based sub-UIs this IPC library is loaded and HUICA plays well with Re-sponsive Design.Multiple HUICA-based Rich-Client and non-HUI-CA-based Thin-Client UIs can be seamlessly inte-grated.Next >