The document outlines a case study on the implementation of a modular front-end in an Adobe Experience Manager (AEM) environment by Namics, a leading Swiss internet consultancy. It details the benefits of using modular design, such as cleaner code and reusability, while also discussing challenges faced and various integration approaches. The presentation culminates in insights into future possibilities with AEM, specifically utilizing Sightly for valid HTML rendering.

1. Connect Web Experience. Basel.
Modular Front-End in AEM. Namics.
Michael Kreis. Software Engineer.
René Bach. Senior Frontend Engineer.
25. Juni 2014

2. Namics.
Agenda.
 Who we are
 Modular Front-End
 Challenges
 Experiences
 Outlook
The challenge of implementing modular front-end in a AEM environment. A case study.
27.06.2014 Denken. Präsentieren. Umsetzen.2

3. Namics.
Who we are.
27.06.2014 3 Denken. Präsentieren. Umsetzen.

4. Namics.
Michael Kreis.
Software Engineer
Namics, St. Gallen
The challenge of implementing modular front-end in a AEM environment. A case study.
27.06.2014 Denken. Präsentieren. Umsetzen.4

5. Namics.
René Bach.
Senior Frontend
Engineer
Namics, Zürich
The challenge of implementing modular front-end in a AEM environment. A case study.
27.06.2014 5 Denken. Präsentieren. Umsetzen.

6. Namics.
Namics.
 Leading Swiss Internet consultancy with a strong
presence in the German market.
 Focus
 Internet Strategy
 Design and implementation of user-centered, efficient and
compelling internet applications
 Marketing and launch support of online activities
 Standards based approach, pragmatic realization
The challenge of implementing modular front-end in a AEM environment. A case study.
27.06.2014 6 Denken. Präsentieren. Umsetzen.

7. Namics.
Namics.
 Facts and figures
 founded 1995 as a spin-off of the University of St. Gallen
 > 430 employees, Revenue 2013 CHF 55 Mns
 Locations: Frankfurt, Hamburg, Munich,
St. Gallen, Zurich
The challenge of implementing modular front-end in a AEM environment. A case study.
27.06.2014 7 Denken. Präsentieren. Umsetzen.

8. Namics.
Modular Front-End.
27.06.2014 8 Denken. Präsentieren. Umsetzen.

9. Namics.
What is a module?
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.9

10. Namics.
What is a module?
Modular Front-End.
27.06.2014 10 Denken. Präsentieren. Umsetzen.
 A module is a unique element that has a specific set of
functionalities and is not tied to the layout of a website.
 Wherever the module resides on the site, it has the same
general sub elements and functionality.
 Modules should be independent of other modules or
layout elements.

11. Namics.
What is a module?
Modular Front-End.
27.06.2014 11 Denken. Präsentieren. Umsetzen.
 A module is a unique element that has a specific set of
functionalities and is not tied to the layout of a website.
 Wherever the module resides on the site, it has the same
general sub elements and functionality.
 Modules should be independent of other modules or
layout elements.

12. Namics.
What is a module?
Modular Front-End.
27.06.2014 12 Denken. Präsentieren. Umsetzen.
 A module is a unique element that has a specific set of
functionalities and is not tied to the layout of a website.
 Wherever the module resides on the site, it has the same
general sub elements and functionality.
 Modules should be independent of other modules or
layout elements.

13. Namics.
Why using modules?
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.13

14. Namics.
Why using modules?
 The code will be cleaner, because CSS and JS of
modules are bundled in an own module-file-structure
 Changes in markup, CSS and JS can be done very
quick, because it's clear where to find it in the code
 Modules are reusable
 Modules can have different representations (“skins”)
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.14

15. Namics.
Why using modules?
 The code will be cleaner, because CSS and JS of
modules are bundled in an own module-file-structure
 Changes in markup, CSS and JS can be done very
quick, because it's clear where to find it in the code
 Modules are reusable
 Modules can have different representations (“skins”)
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.15

16. Namics.
Why using modules?
 The code will be cleaner, because CSS and JS of
modules are bundled in an own module-file-structure
 Changes in markup, CSS and JS can be done very
quick, because it's clear where to find it in the code
 Modules are reusable
 Modules can have different representations (“skins”)
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.16

17. Namics.
Why using modules?
 The code will be cleaner, because CSS and JS of
modules are bundled in an own module-file-structure
 Changes in markup, CSS and JS can be done very
quick, because it's clear where to find it in the code
 Modules are reusable
 Modules can have different representations (“skins”)
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.17

18. Namics.
Getting started with modular front-end
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.18

19. Namics.
Getting started with modular front-end
Modular Front-End.
27.06.2014 19 Denken. Präsentieren. Umsetzen.
 Layout
 First structure your layout (header, footer, sitebar, main-
area,...)
 Figure out variations of layout elements

20. Namics.
Getting started with modular front-end
Modular Front-End.
27.06.2014 20 Denken. Präsentieren. Umsetzen.
 Layout

21. Namics.
Getting started with modular front-end
Modular Front-End.
27.06.2014 21 Denken. Präsentieren. Umsetzen.
 Modules
 Figure out modules
 Don't be to general
 Don't be to specific

22. Namics.
Getting started with modular front-end
Modular Front-End.
27.06.2014 22 Denken. Präsentieren. Umsetzen.
 Modules

23. Namics.
Frameworks
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.23

24. Namics.
Frameworks
Modular Front-End.
27.06.2014 24 Denken. Präsentieren. Umsetzen.

25. Namics.
Frameworks - Terrific
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.25

26. Namics.
Frameworks - Terrific
 Markup
 modules/navmain/navmain.html
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.26

27. Namics.
Frameworks - Terrific
 CSS / LESS
 modules/navmain/css/navmain.less
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.27

28. Namics.
Frameworks - Terrific
 JavaScript
 modules/navmain/js/navmain.js
Modular Front-End.
27.06.2014 Denken. Präsentieren. Umsetzen.28

29. Namics.
Frameworks – Terrific-Micro
Modular Front-End.
27.06.2014 29 Denken. Präsentieren. Umsetzen.
 Boilerplate for Terrific Modules
 Module template generator
 Features
 CSS/JS concatenation & minification
 LESS/SASS support (optional)
 Caching (LESS/SASS) for optimal performance
 Written in PHP
https://github.com/rogerdudler/terrific-micro

30. Namics.
Challenges.
27.06.2014 30 Denken. Präsentieren. Umsetzen.

31. Namics.
Bringing Back-End and Front-End together
 We are using CQ and Terrific
 Development, both back-end and front-end, must be
quick
 The less develpoment dependencies between BE & FE,
the better
 FE should be able to use the same tools in for every
environment
Challenges.
27.06.2014 Denken. Präsentieren. Umsetzen.31

32. Namics.
Experiences.
27.06.2014 32 Denken. Präsentieren. Umsetzen.

33. Namics.
Integration approach I
 Develop FE in standalone Terrific
 Deliver compiled assets
Experiences.
27.06.2014 Denken. Präsentieren. Umsetzen.33
+ Same tools
+ Quick setup
 Different code base
 Hard to keep track of
changes
 Complete FE should be
finished when starting
with BE

34. Namics.
Integration approach II
 Adapt modular concept in CQ
 Only use Terrific JS framework
Experiences.
27.06.2014 Denken. Präsentieren. Umsetzen.34
+ Standard CQ
+ Quick setup
+ Same code base
 Different tools for FE
 CQ instance needed for FE

35. Namics.
Integration approach III
 Fully integrate Terrific in CQ
 Use Terrific modules as CQ components
Experiences.
27.06.2014 Denken. Präsentieren. Umsetzen.35
+ Same code base
+ FE and BE can use their
tools
 Differences between CQ
and Terrific concepts
 Pages / Views
 Assets

36. Namics.
Integration approach III
 Terrific Micro is installed in
component directory
 Exclude Terrific files in CRX
Package
 FE only uses component
directory
Experiences.
27.06.2014 Denken. Präsentieren. Umsetzen.36

37. Namics.
Integration approach III – Component handling
 Terrific modules are used as CQ components
 Own ClientLib for each module/component
 Embed module ClientLibs in
design ClientLib
(/etc/designs/project/clientlibs.css)
Experiences.
27.06.2014 Denken. Präsentieren. Umsetzen.37

38. Namics.
Integration approach III – Asset handling
 No access to Terrific asset folder in CQ
 Copy to design folder
 Maven resource plugin
 Rewrite references in Stylesheets
 Maven replacer plugin

 No direct references in markup possible
Experiences.
27.06.2014 Denken. Präsentieren. Umsetzen.38

39. Namics.
Integration approach III
Experiences.
27.06.2014 Denken. Präsentieren. Umsetzen.39
Available on Github: https://github.com/m-kay/connect-terrific-aem

40. Namics.
Perfect world???
Experiences.
27.06.2014 Denken. Präsentieren. Umsetzen.40

41. Namics.
Known problems
 Markup has to be copied
 Changes in markup do not take immediate effect in CQ
 Terrific does not have the same concept of pages like
CQ
 Different LESS compiler in Terrific and CQ
Experiences.
27.06.2014 Denken. Präsentieren. Umsetzen.41

42. Namics.
Outlook.
27.06.2014 42 Denken. Präsentieren. Umsetzen.

43. Namics.
Possibilities in AEM 6
 Sightly is only using valid HTML
 Can be rendered in Apache and CQ
 Same source even for markup
Outlook.
27.06.2014 Denken. Präsentieren. Umsetzen.43

44. Namics.
Questions? Comments?
27.06.2014 44 Denken. Präsentieren. Umsetzen.

45. Namics.
Thank you for your attention.
michael.kreis@namics.com
rene.bach@namics.com
© Namics
27.06.2014 45 Denken. Präsentieren. Umsetzen.