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?
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.
Wouldn't WPF give you the advantages of easily skinning for different users whilst retaining the rich UI benefits?
It depends on the type of application, but I don't see why that couldn't work. Possible disadvantages: you have to work in HTML and JavaScript, the WebBrowser-component is dependant on the installed Internet Explorer version (not always the same), the UI is not really native and will probably feel like a web application (does not have to be a disadvantage). If I'm correct, I think that the UI of Microsoft Money was entirely based on a WebBrowser control.
I wouldn't recommend using WebBrowser control, if you need to implement any complex functionality. The disadvantages are:
Its behaviour depends on IE version installed, and IE settings, but is not identical to 'real' IE. I saw some cases, when JS functionality worked in a stand-alone IE, but did not work in a WebBrowser control without any obvious reason (and thus without any chance to fix it).
Its hard to customize the UI (alter context menu, make some complex event handlers), as the control doesn't expose much of itself. So, it might be unreasonably difficult to make it interact with the envinronment in the way you need to.
You could consider using a fully web-based solution, working in a stand-alone browser - at least you are much less likely to find an uncommon bug there. An applet or an ActiveX control could be used to interact with the hardware.
Another option is to develop a thin client as a Windows application, that would somehow configure itself depending on the user. If you still need to embed a browser, you could use Gecko (Mozilla's engine) or WebKit (Chrome's engine) - I don't have any hands-on experience with them, but probably they have more consistency between embedded and stand-alone versions.
If you're not losing significant UI features by switching to the web interface, I don't see why this isn't a great solution.
It looks like a great solution, actually. One thing comes to mind, though:
Why not just switch to a full-out web application? Are there certain things you can only do client-side outside of a browser? Because if not, you'll probably get your deployment scenarios greatly simplified by just making the whole thing a web application.
来源：https://stackoverflow.com/questions/1196233/webbrowser-control-as-user-interface