assets parameter added to v1/diff

diff.io recently added a new parameter for incoming requests. By sending an additional property of “assets” with a value of true, diff.io will then include all assets that are generated, in addition to the default composite and montage images. This includes thumbnails, as well as transparent overlays.

The primary use case of this parameter is to get the persistent location of screenshots used in the job, to then use those images in future jobs.

Sound confusing? Consider the use cases below:

Use case #1: you want to have daily differences generated, but you also want to generate a month-to-month comparison, as it represents the changes that occurred during a reporting period.

Use case #2: you want to capture the state of a page prior to a cms, plugin, or module upgrade. Then later, once upgrades have been completed, you can submit a new job for a before-and-after impact assessment. Select representative pages or compare the whole site.

Use case #3: using a service like ngrok.com, developers can confirm the visual impact of local changes against production or prior development version. Understand the impact before even pushing to a remote repository, and certainly prior to merging into a staging/review environment.

In summary, any time you are not following the live page-to-page pattern or live page-to-self pattern, this new parameter is probably useful for you. Creating custom workflows, dashboards, or if you integrate into other applications, make sure you pass this parameter in your call.

 

Update: With the addition of this feature, requests will always create a separate assets.json file in addition to the results.json. This happens even if you did not include the the assets flag.


Looking to build a process or workflow around diff.io, get in touch with matt@diff.io.

ruby example

Don’t worry, a diff.io gem is also in the works 🙂

php example

Don’t panic, a WordPress plugin is in development. As is a Drupal module.

Show HN: diff.io

Greetings to those of you from HackerNewsShow HN 🙂

Here is how it works:

Once you have an account… you send either one or two urls to the api server, as a signed JWT request. Do that as frequently as you desire.

Send a single URL and we visually compare it to the last time you sent us that url.

Send two URL’s and we visually compare them to each other.

If the URL’s are web pages, we generate a screenshot to compare against your prior screenshot. Screenshots are sourced via URL2PNG (we really, really like url2png for rendering consistency). But if the URL’s are images already, we use those directly instead.

This way we can watch any public page, or private pages generated through Travis/Continuous Integration. We can also watch things that aren’t pages, like mobile/desktop apps or the results of process generated media.

Our broad goal is to bring change aware remembrance agents into existence in a major way. Starting with the web sites and images we “visit” each and every day. Or those “visited” by agents on our behalf.

Browsers have recently started using this visual approach for bookmarks and start pages, but really this should be pervasive and engrained in our expectations as consumers.

Here is how it works in practice:

Each account has its own queue, a number of dedicated workers. Upon accepting a job, we write an initial result file, and 302 redirect you to it. Once a worker completes the job, that final URL will contain all the job results and links to visual assets. All jobs are served out of a fastly.com CDN. Events for an account are streamed out over a dedicated pusher.com channel.

We handle scaling and resizing annoyances, and use a tweaked perceptual diff method to only display the most interesting changes. Those changes are served up as a single composition image or as a montage image (before, diff, after). Plus we include thumbnails to make your dashboard/tooling work quickly.

In fact, our optional dashboard is an all-client-side reactJS app that consumes json from the api. It is meant to show the power of the raw service and be easy to use, but we fully expect custom dashboards to appear.

Here is why we are doing this:

During our initial build out we spent months watching the Alexa top 1000. We injected the service into CMS and commerce systems, so that they became self documenting and source of change awareness. Think archive.org in real time, that you control.

There are a lot of services starting to enter this space, and that is really, really exciting. We like our approach for the flexibility and ease of use. We look forward to seeing how others go after the challenge. This, or something like it, is our future.

So, in closing…

When you remember everything and use agents to learn anything, when you can act upon the slightest change, with a history of observed contextual changes… what would you do better? what would you watch? with whom would you share?

We intend to help you find out. Be change aware. 🙂

 

Matt Morley: Founder at DIFF.IO