Webpage App FAQ
What is the Webpage app?
‘Webpage’ is an app that you can add to any media. It adds a dynamic layer to your media item, similar to how you’d add a clock, the date, or other apps.
What makes the Webpage app special is that it will display external websites. It acts like a browser window in your media item. When the external website changes, the Webpage layer in your media item changes.
Note: An alternate name for the Webpage app is “Webview”.
How do I use the Webpage app?
You add a Webpage layer like any other – in the media editor hit (+), select the ‘cloud’ from the speed dial, and select the Webpage app.
You’ll see a new layer added to your media item. Select the layer and hit the settings icon (looks like a round-toothed gear). You enter the URL of your target website and hit ‘Save’. A layer displaying that website will be added to your media. You can resize the new layer just like you would any other.
Will my website play in the Webpage app?
Probably. But it’s not guaranteed. The Webpage app was created as a solution to a particular challenge (display online HTML documents). It’s not a general browser. And not all web pages are created equal; some will display flawlessly, while others won’t display at all. Some will display, but just aren’t designed for the digital signage use case. Your success will come down to the individual HTML page and its implementation. With this FAQ we’ll try to demystify the differences.
However, be warned that it’s a very large topic (the World Wide Web!) and can get quite complex. Your fastest route might be to just try it…copy your site’s URL and paste it into a Webpage layer. If it fails to preview, or previews but fails to perform well on your test player, come back to this FAQ and we’ll help you to figure out why.
What are some common sites that work well with the Webpage app?
The list is long, but here are some highlights:
- Screenfeed
- Flexitive – examples Flexitive 1, 2, 3, 4, 5
- Google Sheets – public
- Google Slides – public
- Google Calendar – public
- Webflow
What type of sites don’t work well with the Webpage app?
Here’s a top 10 of the reasons sites don’t work well with the Webpage app:
- Complex Layouts
If the layout of the site is not designed for digital signage, it won’t look right. For a successful implementation of Webpage, it is critical that the HTML page considers digital signage in its design. By far the most common reason for Webpage fails is that the designer of the site just didn’t envision that it would be used as part of a digital sign. If that’s the case they likely included common elements like:- headers
- sidebars
- embeds
- navigation bars
- buttons and forms
- tiny fonts that can’t be read from a distance
- a main body element that’s cut off from view (like an iframe, image gallery, webcam or video)
- Username and password
The second most common point of failure are sites that require user authentication (a username and password) to access the site’s content.
For example, if you attempt to view a Google Sheet that is not public, Google will deliver a user login page instead of your sheet. Making the document public (instructions here) allows ScreenScape players to access the document directly. - Blocked sites and CORS
Website operators can directly block the use of their site for use in an embedded frame on another site. (That’s basically what a Webpage layer is – an iframe that embeds another site into your ScreenScape media item – which is in itself an HTML page). If the site owner chooses to block embedding of their site, it can’t be used.For example,cnn.com/ blocks their site from being embedded. A variation of this issue is called CORS – Cross Origin Resource Sharing. CORS is technical topic, but the upshot is that some external embedded resources on your site (for example, a Google Map) might get blocked. The good news is that the owner of the site you’re referencing can unblock them if they choose to.
- Internal sites
Websites on internal networks are behind firewalls that may not allow the ScreenScape Webpage proxy to access the HTML page they protect. When blocked by a network in this way the site can’t be embedded in a media item. The reverse might also be true – the firewall of your local area network may prevent your player from accessing the web address that connects to ScreenScape’s proxy server. - Popups
Many sites have user prompts, modal dialogs and advertising popups that block the view of the page. - Navigation and user settings
The design of some sites assume that a user will be present to scroll down, navigate or otherwise interact with the screen to view the desired content. If the page can’t be linked to directly from a URL and viewed without further navigation, it can’t be viewed properly with Webpage.Similarly, the design of some sites assumes that users will be able to select settings on the current page to create a view of specific content. This might include search criteria, a checkbox, view selection, or other user setting that lets users change what’s displayed on the screen. If the user setting does not result in an argument in the URL of the page that can be passed along to the Webpage, the specific view won’t be visible. - Single page apps
Some users want to display graphs, lists, statistics or other information that is embedded in a Single Page Application. This type of app generally requires user authentication, but if it doesn’t, the destination in the SPA will need to be ‘deep linked’ – available directly via URL. - Multiple videos or animations
If a page has a very large number of animated elements, high resolution, uses aggressive animations, or has multiple videos this will affect the playback of the Web Page content. The render time of the page will likely result in delays, dropped frames and choppy playback. These will degrade the viewing experience of the content on the page. - Websockets
Some modern web pages use a communication protocol to display real time data to the viewer. Websockets are good example. Because of the way media items are architected as static web pages, two-way protocols like websockets are not supported. - Incompatible HTML
Outdated HTML, unsupported element types, or non-standard HTML may be unintelligible to the Webpage proxy engine or unrenderable by the Webpage browser.
Can Webpage be used for interactive screens?
For example, if I had a touchscreen display could I use it to navigate my wayfinding site?
Websites that require user interaction are not supported.
Nothing will happen if you click on the screen or otherwise interact with the page, as with a touchscreen. However, it won’t break the display either.
What is the recommended aspect ratio for my webpage design? Should it be 16:9?
The ideal aspect ratio for a ‘full screen’ Webpage is the same aspect ratio of your TV, likely 16:9.
If a site uses responsive design (recommended), it will adjust its output to the size of the window in which its rendered. You can change the aspect ratio of the Webpage layer frame for non-fullscreen Web Pages just as you would for any other layer. Your site will adjust to the aspect ratio of the layer frame (e.g. 1:1, 16:3 banners, 9:16 portrait etc).
We recommend using a tool like Flexitive to design your responsive content. In the case of Flexitive they have a great library of templates well suited to digital signage. You can take the output of your Flexitive design and input it directly to your Webpage app – it will work right out of the box (example above).
What is the recommended image size for my webpage design?
There is no one-size-fits-all. Website image optimization is a big topic (here’s a good starting point from Google and another from an ecommerce incubator). That said, here are some quick pointers.
Not too big and not small. Images that are too small need to be scaled up and will look pixelated and blurry. Images that are too large will need to be scaled down and will lose detail while taking longer to render.
Match your TV. The best way to select image sizes is to identify the resolution(s) the image will be displayed at its destination and match that. You’ll improve graphics performance and playback quality when images are scaled to the output resolution before they are rendered in HTML. You have an advantage over most website producers, in that your final display conditions are narrow and you can identify them in advance.
For backgrounds, try 1920×1080. It’s the most common 16:9 screen resolution out there. When in doubt, that’s a good place to start.
Design Responsively. We recommend that you design your site to be responsive. You can then prepare a range of image resolutions for your images that will adjust to the display conditions at the time the page is rendered.
How long does it take for website changes to show up in a Webpage layer?
On average, 5-10 minutes. This can be sped up or slowed down, depending on the use case. Either way – every time Webpage refreshes there’s a hit to your bandwidth consumption. It’s flushing out it’s old cache and downloading a new version of your target webpage.
Can I use custom web fonts with Webpage?
Yes, you can embed custom Web fonts into your page.
However be aware that the overall performance of the page may be affected by the render time of the font on a player. Also note that if the font file is referenced by the HTML page but not available, text will be rendered using a default system font.
Can I use animations on my page?
Yes, animations are supported.
However the final result, and especially the frame rate performance of your animations, will depend on many factors:
- Animation method (SVG [recommended], Canvas, WebGL, JS)
- Number of concurrent animations
- Size of animation (# of pixels moving at once)
- Current player CPU / GPU load
- Current memory usage
We recommend light use of animations to prevent frame rate drops, since many of these variables are circumstantial and will be difficult to predict in the field. It’s also a solid design principle to avoid making your screens too busy. A little movement goes a long way.
Does the Webpage app support Flash?
No. Flash is not supported.
There is no Flash runtime on the players, so webpages that have embedded Flash content will not render successfully. If it’s your site, we recommend the use of authoring applications like Adobe’s Creative Suite to export Flash content to HTML, and use that on your page instead.
If the site belongs to someone else and they are using Flash, the site can’t be used with the Webpage app.
Does the Webpage app support embedded video?
Yes, pages with embedded video are supported.
However the page will be responsible for auto-playing the video, muting audio, looping, etc. Also be aware that videos affect overall player performance. A video stacked with other visual effects like animations, or multiple videos, may result in frame drops and choppy playback on lightweight players.
Does the Webpage app support live cams?
Yes. A site with elements that stream video, like a webcam viewer, can be displayed in a Webpage layer.
However be aware that live cams require a high amount of bandwidth for your player (a fast connection), and like other videos can consume player resources like memory and CPU. The video element will need to be positioned on the page such that it’s fully viewable on initial page load. The page will need to be designed with these constraints in mind to be successful.
Why does a Webpage layer look different in Preview?
When I view it on my TV, I see more of the page than in the preview on my laptop.
At the end of the day, it’s “just a website”. Website are rendered slightly differently across various platforms. It’s similar to the difference between the same site on your phone, vs on your desktop. On your phone’s screen, you’ll see a slightly different version of the page.
A Webpage on the player is running on a specific hardware and browser platform at the resolution of your TV. When you view the site in a Webpage layer in Preview, you’re using a different combination of hardware, browser and resolution, on a different internet connection to render the site. Each of these factors will affect presentation when the site is rendered.
When using Webpage we highly recommend testing your website’s final output under the same conditions that you’ll be deploying in public. e.g. a ScreenScape player, a full-size TV, a similar WiFi network, etc.
Does the Webpage app use a proxy? (and… What’s a proxy?)
Yes, by default the Webpage app uses a proxy.
A proxy is a server that acts as an intermediary between the website, the Webpage media layer, and the ScreenScape player.
ScreenScape uses the proxy to interpret the contents of the website’s HTML, looking out for parts of the site that might be incompatible with being displayed in a Webpage media layer. When it finds incompatibilities, it makes a best-effort attempt to translate them into usable elements. The success ratio isn’t 100% (the Web is a big place), but it does increase the probability of a successful result.
Can the Webpage proxy be turned off?
Yes, the proxy can be turned off.
Why would you want to do that? In some cases, a proxy can get in the way. The most common of these is when the website in question is hosted behind a firewall. Players that are also behind the firewall could play those websites – but ScreenScape’s proxy server would be denied access by the firewall.
In other instances, there may be an incompatibility between the proxy and whatever website you’re attempting. If a website fails to render correctly with the Proxy on, try turning it off.
Will my dynamic webpage work?
Sadly, the odds aren’t good. This technique (Dynamic web pages) doesn’t mix well with the iframe and static webpage approach in use with the Webpage app. Dynamic fetches of http data with javascript are frequent cause of failure.