My previous post concerning WebDev Dynamic or AWP, lead to a followup question from another user. It’s a question that we get often, and I am willing to bet there is more than a few of you out there wrestling with the question right now as well.

To paraphrase the question: “I have a windows application, I want to offer it as a Web application with the user interface and functionality being identical to reduce future support cost. Can this be accomplished? And if it can, why not just develop a web application, and not have a windows application at ?”

How’s that for a loaded question? Well prepare to climb back up on the soap box with me for my response 🙂

With today’s web technology, you can indeed create a rich interface that can support an rich business application, such as an accounting application. But I think developing a windows and a web application with the goal of the interface being the same, is an extremely bad idea. Many people have tried it and I have never seen it done well. By making that a requirement, you are by very definition saying that you are going to “shoe horn” in one interface or the other, and what generally happens is both end up shoe horned. You strip stuff out of windows, you can’t accomplish on the web, you make the web interface look and feel like windows, and neither is a good thing. You have to embrace the differences between the environments. They can have the same features and functions, at least for the most part, but they don’t have to (and shouldn’t be) pixel perfect clones of one another.

To really answer the question the first thing you need to do, and I touched on it in my AWP ver Dynamic article, is really clearly define your business model and your business needs and go from there. You business and/or marketing needs, if you are a commercial enterprise, need to drive you development requirements. Every situation is unique, but as a general rule my first approach, until proven wrong by true business requirements, is to take a hybrid approach. Generally in a business application there is a lot of functionality that I call “back office” functionality, that would never be done other than on site, so why spend the time and effort to develop them as web in the first place? Likewise there is functionality that can be approach differently for the web, or the workflow be different (with the understanding that it is a user not on location), etc. so often the web portion of those types of applications is very targeted for certain needs and functions that are required to have remote access. An example, you might need to review receiving remotely, but would you ever need to do receiving remotely? So my “default” approach for most projects, is a hybrid solution with a back office windows application, and a specialized web application with the features and functions needed.

Now if true business requirements tell me that everything is 100% required to be accessible via the web, then my “default” approach would be to develop it as a web only application. And again if I did, it would have a “web” style interface, I wouldn’t try to make it look like a windows application. One of the downsides to this approach, if it is used in a traditional back office environment, is you have added the requirement of a web server. Which isn’t really a big deal because you needed a database server anyway. You get the benefit of workstations only needing to be browsers, and not powerful machines. But another downside is, it is very hard with browser applications to take advantage of dual monitor configurations, which are becoming very common in back office environments these days.

The only reason I can envision the requirement for there to be both a windows and web version that is 100% feature/functional identical, is really a marketing requirement. Meaning you are in the business of selling software (either shrink wrap or SAS) and want that as a marketing plus. At that point marketing is driving the business model. It can be done, but you understand from the beginning that you are spending resources to tick a box on a marketing brochure, and have decided it is worth it. Which brings me to my final point. When clients ask me these types of questions, I always pass on one of the best pieces of advice I every got. Companies like Sales Force, Intuit, SAP, etc. have spent more on case studies, A/B testing, etc. than you likely have as your entire development budget, so why not take advantage of that? Take a look at what they have done, what approach they took to this very issue, and decided what you do and don’t like from each approach and come up with your game plan. Hint: They each cracked this particular egg completely different. If you take a look at QB online versus QB desktop you will find out that they are two completely different products, there are similarities but they are not the same product at all. Sales Force is another interesting case study a few years ago they completely revamped their approach and change their interface completely. Now if your goal is to truly disrupt the market, maybe you don’t want to look at what the other guys have done, but then I doubt you would be asking my opinion either :-). And if that is the case, I sure hope you have some deep pockets because disrupting the market requires rowing against the stream and that is an expensive endeavor.

This again was more of a business approach response than technical response, but I will give you one technical hint. If you decide to take the approach of a hybrid or dual interface, then RESTful services are going to be your best friend!. Do all of your database access via REST and standardize your DB approach, so all your business rule requirements etc. are in your RESTful piece, and now all that is in your two applications is true interface code, so you are not investing resources duplicating business logic, and more importantly, maintaining two copies of business logic, that no matter how good you are at some point with end up with differences between them that will cause you support and development nightmares.

• WX