are there web frontend enterprise systems sufficiently uncustomizable to benefit from UI automation?

by UI automation I mean a browser that would automatically perform actions imitating a human user. So, e.g. if a certain action takes 6 clicks and 40 seconds, such automation would reduce it to 2 clicks and 10 seconds. Plus, since several browser windows night be (logically, not visually) open at the same time, the user could do new actions while old ones were being completed. From user standpoint the amount of stuff that’s being displayed on browser screen would depend on what is the optimal amount of stuff to display - from the entire original interface to a pared down web interface to just a few text messages about what has just happened. Browser interfaces are in reality as malleable as Terminator 2, even though people making money from online ads would wish us to think otherwise.

Of course, potential next step might be to start building a SaaS backend to these browser automation wrappers in order to store additional data that does not get currently stored in the underlying system. But that’s getting ahead of ourselves.

Now, presumably a truly good enterprise system would either come already sufficiently usable to avoid need for such mechanical speedups or else would have support for easy backend customization. But, seeing how the world is imperfect and each imperfection just might turn out to be an unfilled market niche, I am wondering if there are systems out there right now that combine sufficiently poor usability, complex or exorbitantly expensive backend customization and big enough maintenance budgets to make their users potential customers for such automation wrapper solutions.

Any thoughts?

I’m not totally sure I understand the question, but I do have two candidates that may be doing what you’re talking about.

TaxScripts is designed as user-interface to the IRS’s E-services website. From their site: “With just a simple click of a button, the software automatically uploads DA and IRS transcript requests through the IRS’ e-services website then automatically downloads the transcript(s) and sends them to your printer.”

I don’t use TaxScripts myself… I detest the IRS’s E-services website to such a degree that I’d rather just sit on hold for an hour to get things done over the phone.

I also know of an HTML-based MMORPG game that used an optional, third-party, browser extension to improve the interface and speed up certain actions. This way, the game could support older browsers through the basic interface and take advantage of some newer features. I’m sure someone here can remember the name - it was set in a zombie apocalypse in which your character could be changed back and forth between a zombie and a human.

Umm…what? Are you talking about browser macros? Self-optimizing browsers? Things that already exist like the Windows option to save passwords and auto-fill forms with demographic info? And how does this differ from just optimizing the web page to start with?

re TriPolar, dftt

:confused: Those were serious questions. What are you asking about?

No, they aren’t. Enterprise web systems aren’t like 35 year old legacy software where you have to pay $130,000 to a consultant to add two new fields to an ancient hierarchical database system.

It’s pretty standard that you have a client side/UI layer, application layer, and data layer in an enterprise web application. Let’s say a company has a web frontend that it needs customized or maybe even wants it redone completely because it is unhappy with it. This company doesn’t have any internal web development staff so they go to a contractor. Well, the current web application’s client layer makes heavy use of ActiveX controls and VBScript. It’s also very poorly designed, with countless nested tables and various other things that make it very hard to work with. In this scenario you have a web application that is using client side technologies that never really caught on and in this case were so tightly tied into using Microsoft Internet Explorer that most web developers in the past 10 years have stayed away from using these technologies entirely. The company that has been hired to redo the frontend just doesn’t have the expertise to ‘clean up’ what was there.

Okay, so they just decide to scrap the entire UI layer and build a new one. Companies that do this sort of front end development can probably get a generic interface to connect to an existing system in place very, very quickly. There are already a lot of packages out there for this, such that it minimizes the amount of actual development needed at all. It’s really just a matter of massaging a generic CMS into interfacing with whatever data or application backend that the company has. Sometimes the longest part of all this will be if the enterprise wants a new look and marketing stuff, because branding companies might take awhile to develop a mockup and logos and such. Then all the corporate marketing people will want to review it, it’ll get kicked back and forth and etc. If the system is more of a business-end user oriented web application that isn’t about marketing and more about serving as a business form or whatever, then the turnaround time should be a lot quicker.

Of course, not all enterprise web applications were properly deployed as multi-tiered applications. I know for example there are a lot of Classic ASP systems out there where all the applications logic and client side stuff is sort of intermixed, so there would be a lot of work to create a new system there. However, most companies would probably want to pay for that work to be done versus paying for UI automation. Mainly because that sort of system is indicative of greater problems and those problems don’t get better over time. In such a situation many companies would much prefer a rewrite. Major web applications actually get rewrites fairly often.

Finally, as has been mentioned the sort of automation you’re talking about is sufficiently vanilla that people have already got stuff that can do it. Some of it is given away freely so I’m not sure how effective your business would be.

[Moderator Warning]

code_grey, you’ve been around long enough to know that calling someone a troll outside the Pit is not permitted. This is an official warning.

General Questions Moderator

*dftt = Don’t feed the troll

Since this is seeking opinions, I am moving it to IMHO.

General Questions Moderator

Martin Hyde,

first of all, my question is narrower than what you seem to be talking about. I am talking about only apps for internal use (where those magic wrapper browsers could be deployed by the employees) rather than the corporate websites that the marketing people care about. Internal use apps also happen to be the stuff that’s under heavy use and ought to work well, since employees are doing stuff with them continually. By contrast, outside world facing sites can remain flashy and uninformative as usual.

Even the most vanilla things require some level of competence to do well. But, in reality, modifications to what/when/why is being rendered in the browser can go far in excess of “vanilla”. All that remains is to find a backend system that is expensive enough to customize at the backend to make such work worthwhile.

Due to ignorance, I don’t know many exorbitantly priced complex backend systems. Well, I do know of the existence of SAP (even though I still don’t really understand what it is about), so maybe that means that there are others as well.

Of course, customizations could be done on non-enterprise, non-expensive systems with inaccessible backend as well. E.g. the user interface of gmail can be reshaped as easily as anything else (at least until they notice and decide to raise a stink). But then, people are happy enough with gmail and can use an alternative email client, so that is not a good place to apply such techniques.

The way you are using backend confuses me.

Most web applications such that you are describing will be at least two-layered and often times three-layered.

Just as a quick example when I was in State government we had a grants tracking web application (this was early 2000 or so.) It was a bear of a system and I wouldn’t be surprised if it’s still being used (it would be very dated by now.)

The system was really an interface for a SQL Server 2000 database. Which means if the Commonwealth of Virginia decided to replace it, they’d most likely just buy a solution like Microsoft Dynamics CRM or something where they could just destroy the entire UI layer that existed before, attach a modern off-the-shelf system to the database and go from there.

Even that system though, there was like two programmers assigned to it, changing forms was not a major deal.

Lots of backend systems are expensive but few of them are expensive and not customizable. For example licenses at the enterprise level for an Oracle database cost tons of money (can run into the millions.) However, because many people will create applications that are n-tiered, the applications and interface layers are independent of the database. Meaning they could replace the entire thing and leave the expensive Oracle database backend in place.

SAP’s ERP system is to my knowledge a different beast because its supposed to be this enterprise wide, integrated thing. It wouldn’t be as easy to replace huge modules of it with non-SAP stuff. However, my understanding is that it’s highly customizable, and that is one of its major selling points, that you can make changes to something that doesn’t require tons of work all across the organization. So in that case the expensive system is directly designed to make the sort of system you are proposing unnecessary.

Even the hellish shithole of awfulness that is SAP runs on top of a gigantic Oracle schema.