HTML (Web Based) Intranet Applications - Is there a better way?

For the last several years the majority of company intranet applications have been developed using a web based interface. The major reasoning behind this has been deployment. A web based application needs to be installed on the server side and as long as the clients have a browser they are able to access the application. However, how many web based applications have you ever seen that function as well as a windows desktop application? HTML or web-based application interfaces are very limited in functionality and the user needs to be continuously connected to the server to work with data. HTML interfaces were originally used for displaying static information, but keep getting stretched to the limit to mimic desktop application functionality. I’ve seen several web- based intranet applications fail miserably because the user experience just does not approach what the desktop application can provide. End users expect a certain level of functionality and ease of use, and unfortunately web applications make this difficult to deliver.

Microsoft’s .Net Framework may change all of that, and once the .Net initiative takes hold in the corporate environment, it may change it quickly. .Net allows what MS calls “XCopy” which means that if the .Net runtime is installed on a client machine, all you need to do is copy the folder that contains the application itself and all of its dependent DLLs onto the client and it will run. The result is no more registering and un-registering DLLs. This once again makes developing Windows Forms-based applications (desktop applications) a viable solution for intranet application development in the corporate environment. With the introduction of web services, clients can now connect to the corporate server, download data onto their laptops via a desktop application into a “dataset,” disconnect from the server, manipulate the data, and save it to their local drive in XML format. Once re-connected to the corporate server, the client application can reload the saved XML back into another “Dataset” (.Net supplies the plumbing to do this for you!) and send it back to the server database. Developers can also use “Remoting” which is the successor to DCOM for intranet data transport. This offers binary data formatting which is considerably faster than the SOAP format which is used by Web Services. Using a combination of these two technologies, crafty developers now have the ability to design and implement an intranet application that can check for the source of a client request. If the user is on the corporate intranet, they can use “Remoting,” as it is much faster and more efficient than SOAP, and if the request is coming over the firewall from a remote site, they can use a Web Service that transports data via SOAP (XML).

As corporate applications become more and more complex, the HTML User Interface becomes more cumbersome to develop. With the .Net Framework in place, developers can now provide fully functional desktop applications (which in general are a bit easer to develop and less time consuming to build than their counterpart web app versions) as a viable solution.

We’ve used the .Net framework here at Knowledge-Management Associates for a defect tracking system that I recently built using “Remoting” and a Windows Service that I developed using a combination of VB.net and C#, and so far we’ve been very impressed by the ease of development and the new exposed functionality and power that is now available to all developers. I also recently built an Excel add-in that uses a Web Service that is located on our corporate server for remote timesheet management. I used the familiar UI of Excel for a rich end-user experience instead of a web browser. The employee can connect to the web service, download their time sheet (or create a new one), save it to their local drive, and, when ready, reconnect to the web service and submit it back to our SQL Server database.

Web-based applications may never go away, but the question is whether we need them on the corporate intranet. With the new exposure to functionality that .Net offers, I believe that there will be a push back to the desktop application as the method of choice for the corporate intranet.