Managing WebBrowser as a user interface

Question

First, a few definitions to make everything clear.

User: living person using software

Client: a company that pays for a user version of our software for its users.

We currently have several applications that will require significant changes to 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 customers increases, it becomes more painful to manage all of these individual releases.

My goal is to switch to one common client that can be configured dynamically based on who is logging in. Since our software requires an Internet connection in any case (it makes extensive use of web services), I only considered using the WebBrowser control in .NET and allowing it to interact (via ObjectForScripting) with the necessary equipment on the computer.

Then the entire user interface is written in HTML / JavaScript and stored on the server, which makes the distribution and maintenance of new user interfaces trivial. A shared client is a little more than a custom web browser that knows how to talk to our hardware devices and can be told to do this through javascript.

I see many advantages for this approach and not too many disadvantages. What am I missing? Why shouldn't I go in that direction?

Answer 1

There are some commercial applications that successfully use this approach. The following are some considerations to consider. In any case, this should not prevent you from trying to approach the approach. The key question you ask yourself is whether the application can be a native web application.

• The web browser control is eating tabs. You can use the tab key to move the input focus to the browser control from the hosting application, but you cannot specify your exit from it (unless you explicitly specify this)

• HTML / Javascript applications are single-threaded. If you need some kind of background processing, you may need to delegate this task to the hosting application.

• If errors occur in the web browser control, they are treated as script errors and are contained within the control. Containment is good. But you can’t even understand that an error condition occurred while building / debugging.

• If there is no network connection, users can see the browser crash page. You cannot preempt this and show your own message.

• Depending on your application and how it is implemented, navigation may seem more sluggish than usual in desktop applications. The page reloads in particular. Careful use of asynchronous AJAX can help ease some or all of this.

• Your users will know that they are working with a web page. The user interface design alone cannot hide this fact. Responsibility and accidental failure will disclose this fact. This may or may not be a problem for you.

• Your application will need to support multiple browser versions. The .NET web browser control is a wrapper around the implementation of Internet Explorer on the user's computer. It will be IE6, 7, 8, etc. Depending on what is installed there.

Answer 2

Won't WPF give you the benefits of easy skinning for different users, while retaining the benefits of a rich user interface?

Answer 3

It depends on the type of application, but I do not understand why this did not work. Possible disadvantages: you must work in HTML and JavaScript, the WebBrowser component depends on the installed version of Internet Explorer (not always the same), the user interface is not really native and will probably look like a web application (it does not have to be a drawback). If I'm right, I think the Microsoft Money user interface was completely based on the WebBrowser control.

Answer 4

I would not recommend using the WebBrowser control if you need to implement any complex functionality. Disadvantages:

• Its behavior depends on the installed version of IE and IE settings, but not identical to the "real" IE. I have seen some cases where JS functionality worked in stand-alone IE, but did not work in the WebBrowser control for no obvious reason (and therefore without any chance of fixing it).

• It is difficult to customize the user interface (change the context menu, make some complex event handlers), because the control does not reveal most of itself. Thus, it would be unreasonably difficult to get it to interact with envinronment the way you need.

You can use a fully web-based solution while working in a standalone browser - at least you are unlikely to find an unusual error there. An applet or ActiveX control can be used to interact with equipment.

Another option is to develop a thin client as a Windows application, which is somehow configured depending on the user. If you still need to embed the browser, you can use Gecko (Mozilla engine) or WebKit (Chrome engine). I have no practical experience with them, but they probably have more consistency between the built-in and stand-alone versions.

Answer 5

If you do not lose the significant features of the user interface by switching to the web interface, I do not understand why this is not a great solution.

Answer 6

This is actually a great solution. However, the thought comes to mind:

Why not just switch to a fully functional web application? Are there certain things that you can only do on the client side outside the browser? Because if not, you are likely to greatly simplify deployment scenarios by simply making all of this a web application.