The Web in the Enterprise
I recently noticed more and more often how badly applications within the typical large-scale enterprise suck, and how much they would profit from some basic Web sanity applied to them. But for some reason, many enterprise software developers, whether they’re working with the .NET platform or with Java (more common among our customers), still believe that their software is different from what people use on the Web.
I’ve become convinced that you need something like an Eclipse RPC or Swing app only in very exceptional circumstances, most of which are usually not there in typical enterprise apps. The benefits of being able to centrally change something without having to deploy some sort of client alone usually outweigh any perceived or real disadvantages. But even if you don’t care about this aspect (because of the super-smart software roll-out solution you have), I still think that there are many more benefits of building Web apps:
- Your users probably don’t care much about the things you think they do. They basically want to find information, enter some data, hit a button, enter some more data, and be done with it. They don’t care about being able to use the right mouse button, don’t care for dragging and dropping things, and entirely happy with a pretty basic design.
- Even if you want to add some of these things, there are pretty easy to do nowadays with simply CSS and Ajax magic (no need for anything fancy like Air or Silverlight or Flash)..
But even if you buy into these arguments, many people still build Web apps that suck. Both within the enterprise as well as on the Web, I think good Web apps expose some, or ideally all of these characteristics:
- There are meaningful “entry points” into the app - URIs. (No, I’m not going to mention the R-word.) It’s simply entirely unacceptable for a Web app to expose only a single URI, break the “Back” button, and disallow linking. Frameworks that don’t support URIs for application concepts, such as every customer, order, contact report, document etc. should simply be banned.
- Application boundaries are a concern to developers, not users. The Web is about linking stuff together, without any concern about application boundaries. There’s absolutely no reason why you shouldn’t be able to follow a link in your CRM application that takes you to a product page in your online catalog, or from a customer record to the information about when they last logged in to the Web site, or from a page that’s part of a complex business process UI to the appropriate documentation and on to the discussion group where you can tell everybody how much it sucks.
- Documents are accessible in a standard way. The idea of accessing any kind of document, such as an insurance application form that’s been scanned in, a letter sent to a business partner last year, or a contract with a business partner, by any other means than an HTTP GET is just stupid.
In other words: Many web frameworks, especially those within the Java space, try to support the development of desktop applications that are delivered over the Web as opposed to “web sites”, and I believe this idea is deeply flawed: Any Web application should be measured against the criteria that are used to judge web sites.
If you are an enterprise developer building applications, I suggest that you consider turning them into web sites instead. Why not do what makes your users happy for a change?
Very nice article.
I’ve been told by some they’re not going to use the web inside like that because no other IT departments are doing s either.
The same group is currently building an extremely elaborate infrastructure to do things like “save a name and address” rather than POST a form using a web infrastructure.
“Many web frameworks, especially those within the Java space, try to support the development of desktop applications that are delivered over the Web as opposed to “web sites”, and I believe this idea is deeply flawed: Any Web application should be measured against the criteria that are used to judge web sites.”
Well said. At least in the Java space, framework/spec developers got their concepts wrong too, starting with the servlet spec. They start with an artificial application boundary, and then lock the users within that boundary.
“If you are an enterprise developer building applications, I suggest that you consider turning them into web sites instead. Why not do what makes your users happy for a change?”
Amen to that. I would take one step further, and ask “framework” developers to write “web site frameworks” and not “app frameworks”.
IMO, the cleansing has to start at the companies/places where specs/tools/frameworks are being written.
Very nice! I agree fully. Regarding your comment, “Many web frameworks, especially those within the Java space, try to support the development of desktop applications that are delivered over the Web as opposed to “web sites””, what kind of frameworks do you recommend for developing more Web-like applications ? Are those something which encourage you to program more like http .. e.g. Jersey or Webmachine ?
As someone who has to deal with enterprise apps -as a user- I have to agree. 1. Nobody should be writing anything that isn’t web based, purely from a testing and support standpoint. 2. They should be real webapps, with bookmarks that work. 3. Most of what RIA apps do is feature creep. Better to be usable in the first place before worrying about richness. 4. These people should embrace testing with selenium.
That said * if you want to provide offline support in exceptional circumstances, there’s value in client code. But as 3G wireless becomes more common, you have to look long term and think “this need is going away” * People writing webapps should target firefox first and foremost. I have to deal with junk written for IE6 that will be updated on that dev team’s schedule, which means nobody can use IE7, IE8. And I cant switch to a different expense paying application, so I am stuck with the pain. One day they will move to IE7, probably by the time IE9 ships. If the developers said “firefox 3+” they not only go cross platform, they dont have to deal with a quirky browser that force updates on new OS releases.
I agree fully with the concerns, but I’ve had a problem explaining to at least one lead developer of a so-called Web application why the concerns are valid. Probably a problem on the side of my eloquence.
I suppose the arrival of the web might finally free us from the rule of the application, something that’s been tried for decades with approaches like OpenDoc (as the superior option to OLE), and others. Seeing how the Google Wave client integrates plugins/extensions using XMPP, even via the network, shows how something like this might actually be within our reach - and all that by leaving developers free to choose any language or platform they like (as long as it supports XMPP backends).
Of course - the future isn’t quite as clear; the iPhone & friends are a bit of a setback in that area by putting extreme focus on the application as a unit of interaction with the device. The webOS design seems to focus more on the users data than on applications.
Well said.
We have a corporate IT issue tracker in use that doesn’t support linking to individual tickets. That is, the tool sends out emails saying “something happened to this ticket you created”, and then you have to navigate the page and search for the item instead of simply clicking a link. I can’t even imagine how anyone in their right mind can come up with something like this…
Subbu: I don’t see what’s wrong with the servlet spec. I’m all for isolating applications, anything else would hardly make sense (if you develop them separately and deploy them separately, how would they interact on the code level in a meaningful way?). The nice thing about the web is that you can simply link different applications together through URIs, and all is nice and fine.
So true. I experienced exactly those flaws you list at my current global employer. Many developer seem to just not understand that there may be users out there who like to link things together between systems…
By stating everything should be web you are showing the same disregard for the end users. The web suffers from lack of control over the environment. Which browser, will they use the browser back button or your apps. The application should be built to make it easy for a users to access and use. If they only access at the desktop, then web may fit. If they need to access iformation offline, then the web doesn’t work. In 10 years you may have internet everywhere, then web only may work. Until then do whats best for the user and don’t shackle them because of technology.
The use catcha is a good example of bad use of technology to solve a perceived problem. Do I the user care about you getting spam? but you make us suffer for it.
“It’s simply entirely unacceptable for a Web app to expose only a single URI, break the “Back” button, and disallow linking.”
I both agree and disagree. If the application is to be treated as a Web site, then the above capablities should be provided. Thaey are part of the UI and should be documented and signed off (and off course will cost more than not providing it.)
However, it it is treated as an application that happens to run in a browser then I don’t believe the above needs to be supported - when last did you see a Windows Forms App with multiple URI entry points, general back button support and linking to any point in the application. For these Web Apps the browser should be launched without menus, back button and multiple entry points suppressed. etc.
In the end features cost money - sure we can make the customer happy, but like anything, it’s not free!
I forgot to add, with the increased use of RIA technologies, like Ajax and Silverlight, the support of the above features is tricky. For instance, what does ‘Back’ mean in an application where the screen is constantly changing due to user interactions?
Therefore, there is a need to distinguish between Browser based applications and traditional web sites, each with it’s own interaction conventions.
Good post!
I already see a lot of web apps in the enterprise world. But what I am missing there is usability i.e. a well-thought-out user interface. No one is really caring about users as users have no choice but using the apps provided.
And URIs as entry points are usually not used at all. With all the distributed information in an enterprise environment this could really give a boost to productivity.
My experience is that, while I tend to agree with your sentiments, not everybody does.
Many architects and users loathe the web, and web applications. They like RIA and thick applications. They hate back buttons. They love sessions. I’ve been fighting this battle for 10 years, and I still see it raging, though the Web has been winning, slowly.
Generally speaking, Flash & Silverlight are a much easier & richerUI development experience for certain applications than AJAX and CSS. This is changing with stuff like GWT, but… a lot of AJAX is still hackery.
Generally the culture of enterprise reuse is server/producer oriented (planned) — “you eat what I make in the way I want you to”. Rather than a more URI / Web oriented philosphy, which is agent/consumer oriented (serendpituous) — “what would people like to eat whenever they want for whatever reason?”
In short, what’s a bug to one is a feature to another. I think this is a generational thing, perhaps.
Hi Stu, all valid points. One thing I strongly disagree with (based on my experience): Architects may loathe the Web, but users generally don’t (even though architects or developers believe they do). Most applications can be done just fine with HTML, CSS and a little Ajax from a user perspective, even though it may be harder on the developers (at least initially).