I want to know how I integrate this API into my tests, what exactly it tells me, and how to use it. How about a free plan to test it out? How about developer docs? How about something more than a few screenshots and a 30 second video that is incomprehensible marketroid speak?
Sorry for the harshness, but I really think visual diff tools are needed for integration testing. I want to figure out which ones are flexible and how they can be used. This site helps me do none of that.
There is still more work to be done on making the service more flexible, mostly just opening up the rest of the api on my end.
How would you describe a CMS that self documents externally?
Perhaps this helps a little: http://blog.diff.io/show-hn-diff-io/ (?)
Would be cool to get a Diff.io driver for it, or something like that...
https://hub.com/bslatkin/dpxdt - Python, Deploys to App Engine / CloudSQL / Compute Engine
https://hub.com/BBC-News/wraith - Ruby
https://github.com/bslatkin/dpxdt - Python, Deploys to App Engine / CloudSQL / Compute Engine
https://github.com/BBC-News/wraith - Ruby
compare bag_frame1.gif bag_frame2.gif compare.gif
cutycapt --url=http://www.xyz.com/1 --out=1.png
cutycapt --url=http://www.xyz.com/2 --out=2.png
compare 1.png 2.png diff.png
I don't actually see the problem here. They provide a real service, so they can demand real money. There are multi billion dollar companies that do less for their users.
Your business model should be as follows:
1. Make something new, useful and free.
2. Get people hooked on it, like a drug.
3. Grow a modest user base.
4. Introduce "value added" features, marked as preview or beta, for enterprise customers and integration into other web services.
5. Once features added in step 4 have matured, remove the beta clauses and slap a price tag on them.
I agree with you about only focusing on the essential at first. I too believe in launching a very MVP and I launched my saas service without even a way to rebill a customer, knowing I had 30 days to finish that. But the plans and subscription are essential for launch unless your product is not stable, in which case you should do an invite-only beta with your friends.
Last Saturday was my kids birthday party. We invited her friends from school. The parents stayed for the party, which turned out to be great. I knew of the parents was a lawyer. I say hi to her and outright ask her if I could drop by her office to talk about making her life easier through the use of software. That is literally what I said. She smiled and said 'Yes! I need to organize myself better. Please, visit me next Wednesday (tomorrow). I will be there and you can help me.'I was afraid of asking here. Lawyers are scary! But they are also the kind of business owner who relies on technology to get their job done. Document management, appointments, client tracking, billing, etc. So I'm going there tomorrow, with absolutely no plan to sell anything. But an interest in understanding what she needs and wants.
Notice that I don't sell one product. I'm looking to build products for them and them charge them a monthly fee. It takes me about a week or so to build something that (barely) works. Which then gives them the chance to use it and give me feedback. Who knows if one of those products will turn into something big? The aim is not to have an idea for a product, but to find actual needs/wants from businesses and building a product to solve it. The exact opposite of what people normally do. Dont focus on an idea, focus on other peoples problems.
That is exactly what I always intend to say, but my brain has this awesome tendency of not knowing what words to put together in what order. Not dyslexic, just very happy all the time.
I have found that in most cases asking for money earlier than later is the way to go. There is a difference between finding users and finding users willing to pay.
There is a different between those types of users, yes, but frankly that is a nicer problem to have than just finding any users at all. What I'm suggesting is not without precedent. Pretty much every SV startup looks to build user base first and monetise later.
But another business model is to grow slowly, focusing on profitability along the way, and this works well for businesses in a niche (Pingdom), with low network effects (Basecamp) or high marginal cost per user (Digital Ocean). If a business with high marginal costs per user and low network effects goes after explosive growth by subsidising users, they run the risk of running out of cash before the point they have enough profit to cover the subsidy.
There are lots of exceptions - Spotify and Dropbox come to mind. But there are lots more forgotten startups that incorrectly thought "If we get eyeballs and engagement, the revenue will follow".
The point is really that this was a Show HN post about a little hack someone put together in probably a single weekend. And with a totally unproven product idea, unexplained use cases let alone what ROI might look like, he has already put in place not just a 1 price plan, but a full swathe from startup to corporate customer. It just seems massively over the top at this very very early stage.
A simple disclaimer indicating that he is monitoring API usage, for now, along with a donation button and a "let's talk if you want to use this in an enterprise environment" etc, would have been sufficient.
I wish the guy well, honestly. But there is something to be said of taking things a bit more slowly and progressively. Verify the product idea is at all viable first. Before showing your full hand with badly conceived product plans. Those plans could very well be doing more harm than good. Until you've gathered feedback from customers you don't know if those $ values are a million miles of the expected mark. And the fact there is no free plan for even limited testing is ridiculous really.
However I disagree that you must start by offering the service for free. By charging from day one, you can limit your user base only to those people who are prepared to pay for it. You're less likely to get explosive growth this way, but it's easier to keep the service running as you're not subsidising freeloaders.
One of the assumptions in an MVP is that people are prepared to pay for the service, and you can only establish that by requiring people to part with cash as early as possible.
On the contrary, i am now tempted to build a "Buy" button on a basic marketing page before i ever write a line of code on future product ideas.
I actually have a use case for this and so do a few people I know, and I'd love to try it out.. But you've got to be kidding if you think I'm going to give out my payment data to try a website version of FollowThatPage.
FREE IS NOT A FEATURE
That's the question you should be answering. Not trying to sell some "self-actuated change awareness" mumbo jumbo. The video literally sounds like an infomercial for a cult.
Sorry for being harsh, but it sounds like you have some cool technology which is unfortunately overwhelmed by terrible marketing.
Meh, I don't think it's that big a deal, nor do I think the marketing is bad. You clearly understood that there was some "cool technology" there, right? And, CI is just one use case, right? Still, while the creator doesn't appear to have designed it so narrowly, you are nevertheless seeing the potential application and inquiring. I'd say that's a marketing win.
Of course, with more interest and feedback, the product and message can be honed.
So, maybe your feedback will help the creator, but there are better ways to communicate your opinion. Don't want to be "harsh"? Then, don't be. No need for the side commentary about cults, mumbo-jumbo, and terrible marketing. Those phrases contributed nothing to your otherwise potentially useful feedback. But, they may be discouraging early words for someone who's just poured a lot into a project.
Similar functionality unless I'm missing something, but more focused on the CI use case than CMS.
 - https://news.ycombinator.com/item?id=9624673
I do see your pointed about CI workflow, but I think visual regressions are the current obsession and a limited use case. A very valuable and useful use case, granted.
But if something like diff.io was in place in your browser, in your content publishing system, in your social networks, having it just in your CI would seem limited. Would you agree?
No, I don't. I have about 0 interest in seeing diffs of social networks or most web pages. It might make sense in a CMS but even there I think most people are better served by traditional textual diffs.
It sounds like you've found a good solution for a medium problem (preventing visual regressions) but want to expand it into a "movement."
Shameless plug: I'm the founder of https://commando.io, and we have a GitHub service that allows users to run scripts (we call them recipes) on push of a repo on servers. You could write a simple recipe in Commando.io in bash to trigger the screenshot on diff.io:
You want to capture that potential future business, and hope that you can convert them to paying customers as they become profitable; you don't want them to go "hey, great idea, but I'm not paying for that" and then implement their own solution.
Especially if the core product can be replicated with 3 lines of code using open source libraries.
> can build themselves for free
Bootstrapping startups should not be focused on trying to save $10/month here and there by recreating microservices. A startup may decide to build their own solution for valid reasons, but it most certainly is not "free".
If you do a free tier, you run the risk of having to support infrastructure for people that will never need to exceed whatever you free limit is, just because they couldn't be bother to do the work themself, even if the tools where free.
You need to validate that people will pay money for this product, and the quickest way to do so is to ask up front. I really don't buy this "Give it away for free, get them hooked and then staple on paid features" approach.
PG said it best: "Better to make a few users love you than a lot ambivalent."
One of the best ways to find out if people love what you're building is to ask them to pay for it.
What I tried and what this site appears to do is a straight pixel change detection, which fails to account for how important that change is. Minor things change on a site all the time it's catching major breaking changes that's hard, say a CSS rule change that looks fine on desktop but ruins the site on mobile.
If anyone is interested in other solutions, ImageMagick has a nice "compare" tool built-in. There are also plenty of open source projects like Huxley, PhantomCSS, etc. I recently saw a demo of Applitools Eyes (https://applitools.com/) and it's quite powerful (though it's a paid service).
Lastly, I did a presentation that involved visual regression testing here: https://www.youtube.com/watch?v=mK0l__jmpTA (starts around 12:25)
Try Browserbite with its feature-based comparison. There are other regression-oriented tools out there as well that use pixel-based methods as well.
Also checkout the following projects, https://visualping.io/ and https://dpxdt-test.appspot.com/
If you are using something like phantomjs to generate website screenshots I wonder how you are dealing with dynamic content. A lot of pages have continuous animations that can screw with simple image diff comparisons. For this reason you may want the option to limit your compare to a subset of the page.
Definitely a useful type of test to have and certainly comes from a place of pain. Last year I worked on a bootleg similar project during the YC Hacks event—it was hard to get it to work right.
Recently Applitools Eyes started gaining popularity for CI-based visual testing, I hooked it up to some Selenium integration tests at work earlier this year and the things it catches have consistently amazed me. Catches nearly all of the bugs that manage to slip past the typical unit / end-to-end tests.
One hard part they navigated well has been the interface for being able to review changes, set new baselines, and set a certain area as "ignored". IIRC they even use some fancy computer vision algorithms to handle slight variations in screenshots (e.g. font alignment false positives).
You can change the highlight-color to green (it is a configuration option), just like it is on the page there:
And the "montage" is called a "composition" in Blink-Diff.
Green lock +
"The identity of this website has been verified by COMODO RSA Domain Validation Secure Server CA but does not have public audit records."
Also a comodo certificate.
I had recently installed new certs, but failed to point it to the ssl-bundled cert and instead it was just the main cert without the intermediates.
Things are happier now: https://www.ssllabs.com/ssltest/analyze.html?d=diff.io&hideR... "A+"
This is really a need for monitoring consistency of UX of any website.
Although I just think you should simplify your pricing model. I don't understand why you are talking about "requests". Who cares about bandwidth today anyway? Just make people pay for the number of pages the frequency of the checks.
Also, you should allow people to set up e-mail alerts when some parts of their website pages change (e.g. payment forms).
I would definitely pay for such product. : )
for a moment you think it is smart enough to realize subject and background and only show you changes on the normalized objects.... but it is actually just an edited image on the other side to add a clean element for the diff.
I could swap it with the real plate and the real plate with a sticker, or something. As a regression I thought it was straightforward. :|
Was the confusion that you thought it was doing something like wordlens: http://1.bp.blogspot.com/-X95Ga7iMP74/T_vjrp2PF2I/AAAAAAAAFM...
You can use SSL installation checker to diagnosis troubleshoots.