Option to snapshot an embed view

[Marshall_Johnso]

Might there be a way to add an option to an embed block to snapshot and convert the embed to a jpg and store that? We use embed blocks to show graphs of current % completion of various task, once we hit a threshold it would be nice to be able to snapshot that embed block and store the result on that date. Probably would store it something like 4 or 5 times as we cross thresholds on a project. Currently the views on those days are lost or have to be manually snapshot and saved elsewhere.

[ScottWorld]

You can’t automate it, but it sounds like you’re looking for the web clipper block.

[Bill_French]

Marshall_Johnson:

We use embed blocks to show graphs of current % completion of various task, once we hit a threshold it would be nice to be able to snapshot that embed block and store the result on that date.

Taking physical screenshots is not in the cards for Airtable blocks (now known as “Apps”), but they probably could support this if the screen capture features were embedded in the apps themselves and assuming Airtable allows access to the Apps’ HTML parent.

Baring this unlikely pathway, there may a better way to think about this problem - charting virtualization.

Imagine every day you capture the data that is rendered in the chart block so you can revisit that “state” of the information. This can now be automated to persist the data as at a certain point in time and/or a specific milestone. This would be accomplished in a separate table whose objective is solely to render historical [chart] views of the data as it progressed through the milestones.

In essence, you are capturing snapshots of the state of the data required for the chart(s). With a comprehensive collection of data at points-in-time, rendering the data visualizations is a simple matter of views and filtering dedicated to making it easy to traverse the historical snapshots.

[ScottWorld]

Bill.French:

Taking physical screenshots is not in the cards for Airtable blocks

The web clipper block supports 3 types of screenshots:

The currently supported attachment field inputs are:

• Add screenshot , which will allow you to capture a selected portion of your screen by clicking and dragging your cursor to highlight a rectangular section of the web page
• Add page screenshot , which will capture a full-page screenshot of the web page you’re currently on.
• Add image from page , which will capture an image by clicking on it. As you mouse over images, the image will be highlighted in blue if it can be selected

[Bill_French]

ScottWorld:

The web clipper block supports 3 types of screenshots:

Yep - totally aware of the features in the Web Clipper.

Unfortunately, it doesn’t check the most important box… automation.

Marshall_Johnson:

Currently the views on those days are lost or have to be manually snapshot and saved elsewhere.

[ScottWorld]

Bill.French:

Unfortunately, it doesn’t check the most important box… automation.

Right, as I mentioned in my original post above.

Although I’m sure there must be some API-based service or JavaScript extension out there that can automatically take screenshots of a webpage. I bet @Moe could create something like this!

[Bill_French]

ScottWorld:

I’m sure there must be some API-based service or JavaScript extension out there that can automatically take screenshots of a webpage.

Yeah, there are many ways to do it from an external programatic perspective, but there are three key gotcha’s -

1. You have to render the page where the block is displayed and that’s not easy to do with security and other navigation considerations to ensure you have the right visual.
2. It’s not easy to automated the capture of just the chart block; you’d have to instrument a way to carve up the image which is tedious and brittle.
3. Browsers change and when they do you get to see just how brittle such an approach would be.

This is why it’s a better approach to simply virtualize access to historical charts by making copies of the data, not the pixels. This approach also makes it possible to enhance the charts as new
charting features emerge and apply the new features to the current AND historical data.

Even if there were a way to capture the pixels, any client of mine would have a very difficult time convincing me to build that.

Sidebar - in 2015 I saved KFC $2.5m bucks doing it exactly as described above. They needed monthly dashboard snapshots for 17,500 restaurants over a thirty-year period and the plan was to snapshot the images. I recommended a virtualized dashboard and we developed just one app that works for all operations from 1998 to somewhere beyond 2028 - 30 years x 12 months x 7,500 (it’s a big number). And the dashboard has been updated three times in five years - all new features run against all historical data.

[Marshall_Johnso]

So you could basically specify the historical date and look at the data then? Neat, but not sure it works with Plot.ly and Mentor Verification manager, its a huge amount of data so we toss all but the latest, but you gave me an idea to check out, thanks. I will also take a look for API-based service or javascript, What I was after was the ability to snapshot and then store than jpg on that date and have it sit in the database. To the other persons comment about web clipper, that doesnt really get to the same idea, too manual. I have a snapshot tool that I can manually use. Now if the embed app could leverage webclipper such that you just clicked on some button in the embed app/block and it would store the image to the associated record with a label you enter that would be perfect.

[Marshall_Johnso]

Can Embed App have a button added to leverage webclipper just for that block as shown, then ask for a label to add it to the existing record as an image on a date with a label. That would be very cool. Just click, type in the label “milestone 1 reached” and have the image get added to the data base for the same record.

[Bill_French]

Marshall_Johnson:

So you could basically specify the historical date and look at the data then?

Yep - time is just a window into the viz-ready dataset.

Marshall_Johnson:

not sure it works with Plot.ly

Plot.ly is just a rendering tool whose output is a function of data. Caching viz-ready data works with all rendering approaches.

Marshall_Johnson:

its a huge amount of data so we toss all but the latest

Sure, it’s huge because it’s not viz-ready data, right? You are essentially forcing the data visualization process to also perform the data aggregation tasks (i.e., for every data visualization - re-crunch the raw data). This is typically, but it’s not a mandatory approach. Why not cache-forward the aggregations needed for the analytics? And if it’s a lot of data, one would want to question the use of Airtable for such information at the outset.

Bottom line - the data you need for analytics is typically a superset of the data captured. Compress that raw data into meaningful concise stories that can be easily managed, reported, and rendered.

Marshall_Johnson:

if the embed app could leverage webclipper such that you just clicked on some button in the embed app/block and it would store the image to the associated record with a label you enter that would be perfect.

Yep, but it would still be manual and humans are at the pinnacle of IT process forgetfulness. :winking_face:

Marshall_Johnson:

That would be very cool. Just click, type in the label “milestone 1 reached” and have the image get added to the data base for the same record.

Indeed! Perhaps useful for many things. But alas, still manual.