I often refer to screen scraping as "click and pray" since the results from it, are at best, Highly Brittle!
But the growing demand for obtaining better performance out of your workers through user optimization technologies is driving the need for better clarity on what works and what doesn't!
So, what makes Desktop Automation better than screen scrapers?
First, Desktop Automation (what OpenSpan pioneered as "Surface Integration") lives inside each running application it's going to automate - like a plug-in. It takes robust control over the UI objects so that you can automate against any object that the user would normally have to interact with. What I mean by living "inside" is that you then have the same control over the object as if we were the developers of the application. You can tell if someone clicks a specific button or changes a piece of text in a field or selects a menu. We don't "hope" we detect that click, we ALWAYS get that click. Likewise we can tell the application to change the text value of a field, or click a button or navigate to a page on behalf of the user. Again, we don't hope the application receives the click and we don't tell the user not to minimize the application or take the application out of focus - since we are living inside the application.
Second, screen scraping is often only used for small batch like operations or simple tasks. Desktop Automation from OpenSpan is running on close to 300,000 real active desktops, in mission critical and hectic environments. On call center agent desktops, on branch tellers pc's in banks, in insurance and healthcare claims environments, airlines, travel and much more. If you tried to extend screen scraping to these environments then the brittle click and pray approach just won't last long at all.
Third, screen scraping technology vendors try to mask the fact they are screen scraping. They hook onto the MSAA band-wagon. MSAA is Microsoft's way to explain how well written desktop applications (to MSAA spec), can talk to each other. Good luck with that considering probably only 20% of the applications even come close to supporting it properly and even then, it's very limited it what you can use it for.
Fourth, Desktop Automation doesn't have to rely on pauses and sleeps (the pray part) to detect when automation can occur. Since we see exactly when an object is ready to be automated against (by the fact it we see when it's created on the screen or page it's on), we know exactly when to automate against it. This event driven model means again, the resilient and robust automations are going to work, each and every time without the delays and "prays" associated with screen scraping.
It is wrong to put screen scraping and desktop automation in the same bucket but since they both claim to automate the UI, it's probably too late to create a new bucket. You MUST however look at the success stories for Desktop Automation. It's running in organizations with instances of over 25,000 desktops, all running powerful Desktop Automation solutions to drive out significant productivity gains from their call center agents and user bases. In some cases, customers are in their seventh year of running projects of Desktop Automation and they continue to expand it's use. With screen scraping, the approach is destined to small click and pray projects with short (weeks/months) at best. Now Desktop Automation is here and has firm presence at some of the largest enterprise customers in the world, and now on close to 300,000 seats, I think, it's fair to say, screen scraping is DEAD and Desktop Automation is very much ALIVE!
But the growing demand for obtaining better performance out of your workers through user optimization technologies is driving the need for better clarity on what works and what doesn't!
So, what makes Desktop Automation better than screen scrapers?
First, Desktop Automation (what OpenSpan pioneered as "Surface Integration") lives inside each running application it's going to automate - like a plug-in. It takes robust control over the UI objects so that you can automate against any object that the user would normally have to interact with. What I mean by living "inside" is that you then have the same control over the object as if we were the developers of the application. You can tell if someone clicks a specific button or changes a piece of text in a field or selects a menu. We don't "hope" we detect that click, we ALWAYS get that click. Likewise we can tell the application to change the text value of a field, or click a button or navigate to a page on behalf of the user. Again, we don't hope the application receives the click and we don't tell the user not to minimize the application or take the application out of focus - since we are living inside the application.
Second, screen scraping is often only used for small batch like operations or simple tasks. Desktop Automation from OpenSpan is running on close to 300,000 real active desktops, in mission critical and hectic environments. On call center agent desktops, on branch tellers pc's in banks, in insurance and healthcare claims environments, airlines, travel and much more. If you tried to extend screen scraping to these environments then the brittle click and pray approach just won't last long at all.
Third, screen scraping technology vendors try to mask the fact they are screen scraping. They hook onto the MSAA band-wagon. MSAA is Microsoft's way to explain how well written desktop applications (to MSAA spec), can talk to each other. Good luck with that considering probably only 20% of the applications even come close to supporting it properly and even then, it's very limited it what you can use it for.
Fourth, Desktop Automation doesn't have to rely on pauses and sleeps (the pray part) to detect when automation can occur. Since we see exactly when an object is ready to be automated against (by the fact it we see when it's created on the screen or page it's on), we know exactly when to automate against it. This event driven model means again, the resilient and robust automations are going to work, each and every time without the delays and "prays" associated with screen scraping.
It is wrong to put screen scraping and desktop automation in the same bucket but since they both claim to automate the UI, it's probably too late to create a new bucket. You MUST however look at the success stories for Desktop Automation. It's running in organizations with instances of over 25,000 desktops, all running powerful Desktop Automation solutions to drive out significant productivity gains from their call center agents and user bases. In some cases, customers are in their seventh year of running projects of Desktop Automation and they continue to expand it's use. With screen scraping, the approach is destined to small click and pray projects with short (weeks/months) at best. Now Desktop Automation is here and has firm presence at some of the largest enterprise customers in the world, and now on close to 300,000 seats, I think, it's fair to say, screen scraping is DEAD and Desktop Automation is very much ALIVE!
