Welcome to Tech Mastery, your expert source for insights into technology and digital strategy. Explore topics like Adobe Experience Manager, AWS, Azure, generative AI, and advanced marketing strategies. Delve into MACH architecture, Jamstack, modern software practices, DevOps, and SEO. Our blog is ideal for tech professionals and enthusiasts eager to stay ahead in digital innovations, from Content Management to Digital Asset Management and beyond.
The below questions asked when the AEM projects adopt the Editable templates.
How many editable templates are to be created?
How to organize the editable template?
Who manages the editable template?
Can we reuse the editable templates across multiple
You can have quite flexible, very rigid templates, or somewhere in between. Adobe does not recommend having more than 1000 templates due to potential performance impacts. Here are a few keynotes to consider when developing this crucial building block:
The unique structure and initial content requirement
Page properties — Page priorities on different page types, e.g., root page, product page, etc
Policy Variations
Style System Variation
Allowed Components
Theming variations — Supporting different themes.
Reusability
Impact — a dynamic connection between the page and the template is maintained; changes to the template structure will reflect any pages created with that template (initial content changes will not reflect).
Access management
Template Strategy:
You should be able to adopt any number of Editable template strategies; some of them are below.
Global Templates — Templates that all the sites hosted in AEM can use e.g
Root Template — Template to create root pages of a website
Content Template — Template with a default header and footer and empty container between header and footer for authoring
Empty Template — Empty template with the container to author the components.
Product Template — Template to support the product pages
Region Specific Templates — In some cases, we may need a region-based template to manage region-specific changes or better access management of the templates. The same global templates can support the region-specific needs, but this will helps to isolate the impacts on region-based websites by the changes on the global templates.
Category Specific Templates — Templates to support specific categories, e.g., microsites. We can use the same global templates to support the microsites, but this helps isolate the impacts on category-based websites by the changes on the global templates.
Site-Specific Templates — Templates to support site-specific needs, site-specific unique structure, and initial content needs; this template is not a global need but to help specific sites.
Template Management:
Template management is another critical factor; who manages the editable templates Development team vs. template-authors, also manage through code repository vs. directly through template editor.
Dev Managed:
The dev team only manages templates/policies
Enable the changes through deployment; the source of truth is the git repo
Still enable a back sync from production author back to code repo to sync any changes enabled directly in prod author
The benefit of this approach is the changes are moved through deployment, which is useful when the team doesn’t include experienced authors to manage the templates. But the concern is dev dependency to enable any template changes — more helpful when the ongoing changes are limited.
Template Authors Managed:
Template authors manage the templates directly in prod author
Enable the changes directly through prod author; the source of truth is the prod author
Still enable a periodic back sync from production author back to code repo to reflect the changes in other environments. This approach will enable the required flexibility to the template authors to manage the template changes; also periodic sync to the code repository to ensure the backup of changes.
Page component:
The Editable Templates are always created based on a Page Component and template type. Whenever possible, ensure the same page component is used to create the templates — some cases exception to create own page components to support unique scenarios.
This will helps you to have complete control over dialogs(use render conditions to manage the display for specific cases), metadata, and other common elements.
Guidelines:
Restrict the templates to specific content paths
Training for template authors — Ensure the template authors are aware of the Editable template management, mainly the dynamic relationship between the Editable templates and the pages created through that — any change in the editable templates(apart from the initial content will impact the existing pages.
Enable the required access management for editable templates — ensure only the specific people (template-authors) have access to manage the editable templates.
Never enter any information that needs to be internationalized into a template. For internalization purposes, recommended using the localization feature of the Core Components.
Ensure template guidelines are created for authors — this will guide the template authors to use the suitable template for page creation.
Allow only the components enabled for authoring.
Templates simplify your page creation workflow. However, too many templates create management overheads. Also, too few templates can lead to issues like global impact on template changes. A good rule of thumb is to keep the number of templates as minimal as possible by considering all the key factors discussed above (maybe below 100 ).
The static templates are still supported but use editable templates when starting building new projects. Also, migrate editable templates whenever undergoing significant changes in the current experience. But still can use the existing editable templates. There is no hard rule to migrate all the static templates to editable templates but migrating whenever possible as an Editable template is the recommended approach from Adobe.
AEM also now supports Quick Site Creation, creating a site very quickly using a quick site creation template — this will use the Editable templates and core components to create sites. Refer to Quick site creation | Site Template in AEM(Adobe Experience Manager) for more details on Quick Site Creation.
This post discusses enabling the PWA feature for AEM websites using AEM core components and page properties.
Progressive Web Apps (PWAs) are web apps that use service workers, manifests, and other web-platform features combined with progressive enhancement to give users an experience on par with native apps.
Progressive web apps (PWAs) enable immersive app-like experiences for AEM sites by storing them locally on a user's machine and accessible offline. A user could browse a site while on the go even if losing an internet connection. PWAs allow seamless experiences even if the network is lost or unstable. The user has a local copy of the site with PWA, giving an app-like experience even without an internet connection.
Key principles a web app should try to observe to be identified as a PWA
Discoverable — can find the content through search engines.
Installable, so it can be available on the device's home screen or app launcher.
Linkable, so you can share it by sending a URL.
Network independent, so it works offline or with a poor network connection.
Progressively enhanced, it's still usable on a basic level on older browsers but fully functional on the latest ones.
Re-engageable, so it can send notifications whenever there's new content available.
Responsively designed, it's usable on any device with a screen and a browser — mobile phones, tablets, laptops, TVs, refrigerators, etc.
Secure, so the connections between the user, the app, and your server are secured against any third parties trying to access sensitive data.
Benefits of PWA:
Mobile First
Behave Like Native Apps
Quick and Easy To Install
Sending Push Notifications and other hardware features
Enhanced Performance
No App Distribution Platforms(App Store) Required
Operating Offline
Platform and Device-Agnosticism
Enhanced Security
Increased conversion rates
Improved user experience
The tools such as Lighthouse can measure the completeness of the web app as a PWA, e.g., the site not enabled with the PWA feature.
Technologies used:
PWA is not a single technology but uses next-generation application programming interfaces (APIs) to incorporate features typically associated with native apps. These features include the ability to work offline, support for directly accessing a device's storage and other hardware resources, and an interface resembling a native app rather than a website. e.g.
Most of these technologies are now supported on modern browsers but need to factor cross-browser and legacy browser supports while building the PWA's.
High-level steps to enable PWA:
Create your application manifest — This file defines how a device should display a PWA to the end-user. The manifest file makes it possible to create installable PWAs and appear to the user as if they were native apps.
Create Icons — The Icon displays an icon for the app when the user installs the app in their application drawer. A PNG or a JPG will work fine.
Enable Service worker — Service workers are scripts that act as middlemen between the web browser and the network. By intercepting network requests, they can process them in ways a conventional web app cannot. The Service Workers help the PWAs provide access to native device interface and hardware features.
Enable HTTPS — The HTTPS protocol provides a secure transport layer that encrypts traffic as it passes between the app and other network locations (localhost work for testing without enabling the HTTPS)
"Add to home screen" is a feature implemented by mobile browsers that take the information found in an app's web manifest and uses them to represent the app on the device's home screen with an icon and name. The app is installable(install prompts to display) only if the app meets all the below requirements
Have a valid web app manifest
Be served over HTTPS
Have a valid service worker registered
Be visited twice, with at least 5 minutes between visits
In addition to the browser-provided install experience, it's possible to provide your custom install flow directly within your app.
Splash Screens:
While the user opens your PWA on their home screen, the default behavior shows a white screen until the PWA is ready. The default behavior doesn't feel very nice; adding a custom splash screen makes your PWA feel like a native app.
Chrome for Android automatically shows your custom splash screen so long as you meet the following requirements in your web app manifest:
The name property is set to the name of your PWA.
The background_color property is set to a valid CSS color value.
The icons array specifies an icon that is at least 512x512 px.
The specified Icon exists and is a PNG.
On Android, this works ok; however, iOS does not support a similar method of automatically showing a splash screen. Instead, you need to provide splash screens tailored for each iOS device using the <link rel="apple-touch-startup-image" /> HTML meta tag(Currently no option to enable apple-touch-startup-image to provide splash screens tailored for each iOS device)
Let us quickly see how to enable PWA features for the AEM websites — I am using Local Cloud SDK and a sample project created through the latest arch type for demo.
Core component PWA support:
Core Components release 2.15.0 and later fully support the PWA features of AEM sites. Since AEMaaCS always includes the latest version of the Core Components, you can leverage PWA features out-of-the-box.
Open the page properties of your root page e.g./content/pwademo/us/en
Select Enable PWA on the Progressive Web App tab
Define the Start URL — the preferred URL that should be loaded when the user launches the web application
Select the Display Mode — The display mode changes how much of browser UI is shown to the user and can range from browser (shows the entire browser window) to fullscreen (when the app is full-screened).
Standalone (Like a Native app) — The application will look and feel like a standalone application
Browser (Like a web page in a full browser window) — The application opens in a conventional browser tab or new window, depending on the browser and platform.
Minimal UI (Like a native app but with minimal navigation browser controls) — The application will look and feel like a standalone application. Still, it will have minimal UI elements for controlling navigation.
Full Screen (Like a native app in full-screen mode) — Uses all the available display areas and won't' show the user agent chrome.
Select the Screen Orientation — defines the default orientation for all the website's top-level browsing contexts.
Any — follow device orientation
Portrait
Landscape
Set the Theme Color — defines the default theme color for the application
Background Color — represents a placeholder background color for the application page to display before loading its stylesheet.
Specify the Icon — Icon for the app. Currently not able to provide multiple icons tailored for different devices.
Cahe Management — Select the caching strategy.
Moderately (Stale while revalidate) — This strategy checks for the response in the Cache. If available, it is delivered, and revalidate the Cache. If it is not available, the service worker fetches the response from the network and caches it.
Frequently (Network first, cache fallback) — This strategy will try to fetch the response from the network. If it succeeds, it will cache the response and return the response. If the network fails, it will fall back to the Cache and respond there.
Rarely (Cache first, network fallback) — This strategy will look for the content in the Cache first and, if not available, it will fall back to the network to retrieve it; if it succeeds, it will cache and return the response.
Files to cache for offline use — File to be cached to make web app functional in offline mode.
Select the required client libraries for caching
Add the paths included for caching
Add the paths excluded from caching
Save the configurations; now the site is enabled for PWA
Lighthouse report shows the PWA is enabled and all the checks passed
Also, now the browser displayed the install option to install the app to the home screen.
Click on install open the app also adds a shortcut to the home screen; you should be able to uninstall if required.
Next time open the app from your home screen shortcut
The Cache will serve the app if your server is unavailable or there is no network connectivity from the client machine.
Reference the manifest and service worker path from the source view.
The Developer console helps you review the Service Worker details; the service-worker uses the Workbox library; Workbox is a collection of libraries and tools used for generating a service worker and precaching, routing, and runtime-caching.
Note: You can use chrome://serviceworker-internals/ URL to view all the current service workers.
While configuring the PWA properties internally, AEM creates etc mapping for manifest and service worker paths.
The sling match is not working as expected for the manifest file; the sling match should be [^/]+/content/pwademo/us/en/manifest.webmanifest, update the mapping for testing, I feel better to enable the mapping from the dispatcher to support the site-specific manifest and service worker URL's
Please note the sling match value reverts to the original value on every change of PWA configurations from page properties.
The Cache storage can be reviewed through the Developer console and deleted if required.
The customized app install flow can be enabled using the required event handlers (enable through custom script file)— refer to https://web.dev/customize-install/ for more details.
You can't customize the default PWA service worker enabled by the AEM to handle the push notification — the page properties can control the Service Worker properties; create a custom service worker to support push notifications and other hardware features.
The caching is essential to make the PWA app function optimally; enable the required cache headers for different file types through the dispatcher or directly from AEM. The Cache header for the manifest file and the service worker is already enabled; you can override if required through the dispatcher.
Also, configure the required Caching Strategy through the page properties configurations.
We will not be able to customize the service worker currently(you can control the Service Worker properties through page properties), sometimes the customization of the service worker may require handling additional scenarios e.g offline pages — display the cached version of the offline page while the user or the server is offline.
As we discussed earlier using PWA(Progressive Web App) offers several benefits; same time it has some restrictions
No access to apps stores
Not all Hardware functionalities of the device can be used e.g Bluetooth or NFC
The PWA and its compatibility with (mobile) browsers and operating systems are still under development
The performance of native apps is still much higher than that of a PWA
Browser or OS support — some of the advanced APIs are still not supported by IOS/Safari and some of the other browsers and legacy versions.
The PWA app is simple to start with an easy to manage to compare to native apps; same time provides support across multiple devices and browsers. The PWA apps help to improve the conversion rate and user experience quickly. Still, the PWA won't completely eliminate the native apps, the PWA vs Native App(In some cases you may need both) approach should be defined by reviewing the pros and cons of each approach and the business requirements.
