Question : Deep Dive into WWW cards. Displaying difficult URLs

Usually web page window limits are on the website themselves. Modern HTML5 will have multiple values for the different screen formats (mobile, tablet, desktop, etc.).

The device will announce it’s resolution and the web page will align itself to what was provided. Sounds like the original coder locked it in.

Just to be sure, though… This doesn’t happen with all content, right? Just this one web card?

Have you tried the legacy web page card?

it is just the one card.  The reporting tool was written about 15 years ago.  I am sure the developer had not started using CCS or any type of site structure.  It was a combo of hand-coded and SQL reporting tools.    Unfortunately it is trapped in the limbo between, “we lost the source code and it’s too old to update”, and “we don’t have the budget to have someone develop a replacement for it yet.”
So, I am trying to find a way to get appspace to “adapt” the webpage.

One suggestion I had was to go into the chrome management page, set up a whole new organization unit, place the screens in that org unit, and then use Chrome to force the screen resolution of the devices to match the older size.  

The drawback is that any other content I want to display would be too large, or might have the same issue in reverse.  

My goal has been to find a way to “just make it fit”
I really wish the “Uniform Fill” worked for webpages.

Hey ​@WKK_Mike - this kind of thing is always tricky! Have you tried the using the iframe option in the Webview Card and setting the website scaling option to “custom size” so that you can specify the exact resolution?  I’ve also done similar things by using the “Web (Legacy)” option under the Legacy category. It lets you enter a full HTML snippet, so I’ve used that configuration and created my own size-limited iframe code to paste in there. Basically the equivalent of getting “embed code” from Youtube or wherever.

I have tried both the iframe mode on the webcard, as well as putting a wrapper in front of the card using an HTML snippet.
The SQL reporting tools do not seem to cooperate with those options.  The webpage fails to load at all.
I have considered writing a “web scraper” to run on another web server in-house.  That server would be able to load the URL as it wants to load, perform a virtual screen-shot, then scale the graphic image to fit on the screen.


I know that if I hook a mouse up to the Chrome Box I am using, when the URL loads, I can use the mouse wheel to adjust the browser “Zoom” and make the image much larger.  That will usually hold for a few days.  Unfortunately, it impacts all the other cards that are displayed also.

I have not had time to dig into the way everything works yet.  I hope is that there is some way to adjust the web-browsers “zoom” per page.

Watching the page load on Desktop machines, I can see the forced alignment being used to get headers and columns from SQL reporting tools to line up with data that is generated on the fly by script on the website.   My guess is the developer broke a lot of development rules to make everything line up correctly.  Now, in a post SVGA world, the page just does not scale.  1024X768 is where it wants to live.

As an Update:
Right now we will load the card per usual, and set the time on the card to a comfortable 60 seconds.
Then plug in a mouse and keyboard to the display that for that card.

When the card comes up, we will use the CTRL+Mouse wheel to zoom the screen to the level we want.
 

SOMETHING remembers the zoom setting because every time the card comes back up, it stays at that zoomed level.
We discovered this permanence by accident and we are still not sure what part of the system is remembering the manual zoom change.

It does not impact other cards on the screen, even other web cards.

Now I am even more frustrated.  Somewhere there is a register that holds a ZOOM level and I don’t know where it is or how to access it.

I can’t find a “Zoom Setting” I can put in a URL to instruct the browser to adjust the scale of the webpage.

Once in a while, usually after a power down or a change that causes the card to reload, we need to manually adjust the zoom again, but it will stay for weeks at a time.

Still researching...

​@WKK_Mike regarding your update on the zoom levels, it sounds like you’ve stumbled onto a classic "phantom setting"—which is both a relief for the visibility issue and a bit of a headache for consistency!

After some research here is what I found that may help - Since Chrome typically caches site-specific settings (like zoom levels) based on the URL or Domain, it’s likely that the Chrome instance on your device is pinning that zoom level to that specific card's web address. It’s a great "accidental" win, but I totally get the frustration of not being able to hard-code it for when the power dips.

A Couple of Ideas to "Lock It In"

• CSS Scaling: Instead of relying on the browser's manual zoom, you might try adding body { zoom: 150%; } (or your preferred percentage) to the CSS of the card itself. This would make the scale permanent regardless of power cycles.

• Viewport Metadata: Adding a <meta name="viewport" content="initial-scale=1.5"> tag to the HTML header of the card can often force the browser to load at a specific scale by default.

• Device Properties: Since your CSM and AE are already prepping to reach out, this "permanence" mystery is a perfect technical deep-dive for them. They can help identify exactly where that register lives in the AppSpace/Chrome handshake so you don't have to rely on manual adjustments.

I’m glad you found a temporary fix that keeps the team from squinting! Be sure to talk to your Customer Success Manger and Account Executive when you schedule that call about this and let us know if any of the above work. 

I am going to try the {meta… scale-1.5} first thing tomorrow.  
Where would the  body{zoom} CSS code be attached to the “Card itself”?  Is there a way to append CSS to the card independent of the content from the URL?
(Other than Iframe,  I have not had an Iframe success yet.  Every site I try seems to crash out when embedded)

​@WKK_Mike it’s definitely a bit of a trial-and-error process to get external URLs looking perfect. Here’s some quick tips on where to apply those scaling fixes:

Where to attach the CSS: If you switch to the Web View card (which is more robust than the standard WWW card), you’ll find a "Custom CSS" field in the card properties. You can paste your code there: body { zoom: 1.5; -moz-transform: scale(1.5); -moz-transform-origin: 0 0; }

A Simpler Workaround: Since browser security (CORS) often prevents injecting CSS into third-party sites from the outside, the most reliable method is using the "Scale" or "Zoom" property in the Appspace Card's Layout settings. This scales the entire viewing window smoothly without needing to modify the website’s original code.

Regarding the Iframe Display: If a site doesn't load in an iframe, it’s usually because that website has high-security headers (like X-Frame-Options) designed to protect its content from unauthorized embedding. Appspace simply respects those external security protocols.

Recommendation for today: Try the Web View card with the "Native" resolution setting. It handles high-resolution scaling very gracefully and often provides a polished look without needing any manual CSS hacks!

FINGERS CROSSED 🤞🤞