Custom Tabs - Different options to include a website in the e-paper custom tab

What options does the customer have?

• Ordinary (Traditional) Website 
• SPA
• (RSS feed - cannot be offered at this point)
  
  

Summary

What do all options have in common?

To implement any of the options below, we’ll need a URL to add in Prenly Workspace.
Please note: The page must not include any links, buttons, or content that could lead to a purchase or subscription page. This includes messaging or references about signing up, subscribing, or pricing.

Also, if viewed on an Apple device, the page cannot mention Google, Android, or related services - and vice versa, pages viewed on Android devices should not reference Apple or iOS.

When setting up the external link (the Prenly Workspace term for the custom tab) in Prenly Workspace, the customer needs to set a name for the tab, select a tab icon, and provide the URL. If the web page (the URL) does not provide its own navigation functionality for the reader to back/forward, then it is recommended to enable “Browser navigation”. This would add a small navigator at the bottom of the page and above the menu bar on iOS devices. Commonly, ordinary websites do not provide this but, commonly, a SPA variant will.

When embedding an external web page in a custom tab it is isolated from the rest of the app. This means that page menus, engagement tracking, cookie usage or similar are not shared with the rest of the e-paper app. In other terms, the customer must create their own menu, if needed, on their page for the current custom tab view.

Link behaviour

Since the webpage is HTML, link behavior is determined by the target attribute set on the anchor tag element (the link) to mimic a traditional web browser.

• If no target is specified the app will try to “open the link” in the current view (same WebView).
• Any non “_blank” targets will be treated as a default link and open in the current view.

If the target is “_blank” the app will try to open a new browser tab/WebView tab and follow the link.

An SPA will commonly control the links to keep the user “within the app” where it is common not to provide any target attributes. Commonly, _blank targets are low or non-existent as it would mean the user “leaves” the “app feel” provided by the SPA.

HTTP Headers

HTTP headers are additional information exchanged between your browser (or app) and a website to guide how requests and responses are handled. They are part of the HTTP protocol and are managed automatically by browsers, servers, or frameworks. Every webpage interaction includes request and response headers.

There are three Prenly custom HTTP headers a customer can use to help identify the device and user status, allowing tailored content for each user, where each custom HTTP header needs to be enabled:

• "X-Prenly-Client-Type": Specifies the client type (“android” or “ios”) based on the app making the request. This helps the server deliver platform-specific assets and debug platform-specific issues, or simply render the content differently per platform.
• "X-Prenly-Is-Logged-In": “1” if the user is logged in, “0" if not. It can be used to control access to protected content.
• "X-Prenly-Logged-In-User-Id": Contains the user ID if the login system allows it and has been approved. This requires special approval as it exposes GDPR-sensitive data. If enabled, this supports rendering personalised content, or other actions that require the user’s ID.
  
  

JS Bridge

Since the external link is considered separate/isolated from the app there are circumstances when the external link custom tab needs to “access” information from the e-paper app, for example, what consent the user gave. To “bridge” the boundary between the custom tab and the app the customer will need JS Bridge. 

On this page, you can see an example of how to use the JS Bridge: https://jsbridgedemo.tiiny.site/ 

You can also find the documentation here: https://github.com/Textalk/prenly-js-bridge 

Ordinary Website 

What is it? 

On traditional websites, navigation triggers a full page reload for each click, refreshing the browser to display new content. This happens because the browser requests a new HTML document (a ‘document request’) to display an updated view.

What are the benefits? 

This is the easiest way to include the customer’s website in their apps. The URL to the page already exists and the customer can simply add it in a new external link in the app. 

What are the drawbacks?

• Every click reloads the entire page, which can feel slow and interrupt the flow compared to the smooth experience of a SPA.
• If the landing page isn’t mobile-friendly, it might come across as cluttered, hard to navigate, or out of sync with the app’s look and feel.
• Traditional websites lack the dynamic, app-like interactions/feel that SPAs offer, making them less ideal for news articles or content that updates frequently.
  
  

In which case do we recommend clients use it?

• Low technical expertise: This option is ideal for customers without technical knowledge or a developer on hand.

• Simple content integration: If the goal is to display static or additional information (e.g., contact details, event pages) rather than interactive features or frequent updates, a traditional website is sufficient.

• Quick implementation: When a fast and straightforward solution is needed, adding an existing webpage to the app can save time and effort.
  
  

Examples of clients who are using it

Slovenian: Vestnik 

German: Kleine Kniffe
Swedish: Hifi & Musik
Danish: Indre Mission / Impuls
Finnish: Viisas Raha
Dutch: Fonk Magazine

SPA 

What is it? 

SPA (Single Page Application) allows seamless navigation by dynamically fetching and displaying new content without reloading the page (i.e. by the web browser making a document-type network request). Unlike traditional websites, which use navigation events to load new pages, SPAs use transition events to update content within the same page. A SPA commonly uses a dedicated  GUI (Graphical User Interface) with buttons or menus to navigate between “pages”. Each rendered page is rendered by the client (web browser) instead of rendered by the server for a traditional page. Content is fetched from the server,CMS, to be rendered “on the fly” by the web browser ensuring new articles appear without manual updates affording a more app-like user experience. In short, an SPA is dynamically rendered by the web browser.

What are the benefits? 

• SPAs update content on the same screen without switching to a new page, offering a smooth, intuitive experience similar to mobile apps. 
• After the initial load, SPAs can feel faster since they fetch only new data instead of reloading the entire page, making them ideal for frequently updated content like news. 
• Developers have full control over rendering, turning raw data into user-friendly visuals efficiently, reducing processing, and ensuring responsive performance.
  
  

What are the drawbacks?

• SPAs rely on JavaScript, which can cause compatibility issues with outdated browsers when the SPA relies on a specific Web API, for example social sharing, requiring developers to add fallback code and in turn increases complexity. 
• Rendering occurs in the user’s web browser on their device, where the web browser commonly processes raw data (e.g., JSON) and downloads large files upfront, making the initial load slower than traditional websites. This process also consumes more battery and processing power, affecting mobile devices or older hardware. However, after setup, SPAs tend to respond faster as no additional page loads are needed.
  
  

In which case do we recommend clients use it?

• When the goal is to create a seamless, responsive design similar to a mobile app.
• Ideal for content with the latest news or live updates where content refreshes dynamically.
• Suitable for clients with a developer who can handle JavaScript-heavy projects and how to optimize for different devices and browsers.
  
  

Examples of clients who are using it

• HSS - eVBL
• Svenska Epoch Times - Epoch Times

RSS feed 

What is it? 

An RSS (Really Simple Syndication) Feed is a standardiszed format for delivering regularly updated content, such as news or blog posts. To use an RSS feed, you need an RSS player, which reads the feed and displays the content. The appearance and navigation experience depend on the specific RSS player being used. 

What are the benefits? 

An RSS feed is easy to set up and suited for delivering simple, automated content updates with minimal effort. 

What are the drawbacks?

The design and user experience rely entirely on the RSS player, offering limited control and customisation over how the content is displayed or interacted with. Compatibility with different RSS players can vary, and some features may not work universally.

Why can we currently not implement RSS feeds?

An RSS feed is structured XML data, not a standard web page. Since our custom tabs require a direct URL, an RSS feed cannot be displayed without additional processing. To make an RSS feed readable in a custom tab, it would need to be converted into an HTML page. 

We do not currently offer an RSS player. This means that RSS feeds cannot be displayed in a custom tab without being transformed into a readable web page. However, if you can convert your RSS feed into a readable URL, we are happy to implement it.

FAQ

How long would you estimate it takes to build a SPA?

The time required depends on the developer’s experience and the complexity of the SPA. In general, building a basic SPA can take around 1–3 development days, with design, development, and testing.

Can we display ads?

Yes, you have full control over the content displayed in your custom tab. The only restriction is mentioning Apple or Google, as this could result in the app being rejected during the review process.

What is the recommended number of menus in a SPA for the best user experience?

When adding a menu bar within the SPA to allow readers to switch between different pages, consider how many menus are really needed. Since the SPA is embedded in an app that already has multiple tabs, an overly detailed menu can feel cluttered. To keep it user-friendly, we recommend keeping the menu minimal and focused.

Do external links from our articles automatically open in a web browser, or does it depend on our own hyperlink settings?

The link behavior is depending on the target attribute. If you do not specify a target attribute, or set it as (_self) the app will treat it as the default target behaviour, which means that the link will be opened within the current view.

Can we force certain pages to open in a web browser instead of in the app, for example by using target="_blank"?

Yes, this is possible. By setting the target attribute to _blank, the app will attempt to open the link in a new browser tab or WebView.
However, in SPAs, this is not commonly used, as it breaks the seamless “in-app” experience that SPAs are designed to provide.
Do I need to implement a refresh function for article pages in the mobile app when users scroll down?
We recommend adding a refresh or reload function to ensure the page updates properly as users scroll down.