WebBrowser control as User Interface

Question

First a few definitions to keep things clear.

User: A live person, using the software

Client: A company that is paying for a customized version of our software for their users.

We currently have a few applications that are going to require significant changes in the user interface based on which client the user belongs to. We currently have a separate build for each client, but as the number of clients increase, it's becoming more of a pain to manage all of those separate releases.

My goal is to switch to a single generic client that can be customized dynamically based on who is logging in. Since our software requires an internet connection anyway (uses webservices extensively) I was contemplating just using a WebBrowser control in .NET and allowing it to interact (via ObjectForScripting) with the required hardware on the computer.

Then the entire user interface is written in HTML/JavaScript and stored on the server making distribution and maintenance of new user interfaces trivial. The generic client is little more then a custom web browser that knows how to talk to our hardware devices and can be told to do so through javascript.

I'm seeing a lot of advantages to this approach and not too many disadvantages. What am I missing? Why should I NOT go this direction?

Answer 1

There are some commercial applications out there that use this approach successfully. The following are some considerations to keep in mind. These shouldn't stop you from attempting the approach anyway. A key question to ask yourself, though, is whether the app could be a native web app instead.

• The web browser control "eats tabs". You can use the tab key to move the input focus into the browser control from the hosting application, but you cannot tab your way out of it (unless you code for that explicitly)

• HTML/Javascript apps are single threaded. If you need any background processing, you may need to delegate that task to the hosting app.

• If error conditions occur inside the web browser control, they are treated as script errors, and are contained inside the control. The containment is a good thing. But you might not even realize an error condition has occurred while building/debugging.

• If there's no network connectivity, users get to see the browser's failure page. You don't get to preempt that and show your own message.

• Depending on your application and how it is implemented, navigation may seem more sluggish than is common in desktop apps. Page reloads in particular. Careful use of asynchronous AJAX can help alleviate some or all of that.

• Your users will know they are working with a web page. UI design alone will not be able to hide that fact. The responsiveness and the occasional failure will disclose that fact. This may or may not be an issue for you.

• Your application will have to support several browser versions. The .NET web browser control is a wrapper around the Internet Explorer implementation on the user's machine. That would be IE6, 7, 8, etc. depending on what's installed there.

Answer 2

Wouldn't WPF give you the advantages of easily skinning for different users whilst retaining the rich UI benefits?