Designing for Web or Desktop?
Paul D. Sheriff
Summary: Learn about the advantages and disadvantages of using both Web and desktop user interfaces (UI), and gain an understanding of how to weigh other factors that need to be taken into account before deciding on the final user interface for your application. (8 printed pages)
- Learn the features of Web development
- Learn the features of desktop development
- Compare and contrast the two
The following should be true for you to get the most out of this document:
- You understand Microsoft® Windows® application development techniques
- You understand Web application development techniques
When you begin any new development project, you need to decide which technologies you will use to develop the application. There are a wide variety of languages to choose from, various database engines you can employ, and you need to choose a style of user interface to use. In all of these areas, you need to weigh a lot of disparate criteria when deciding on the best technologies for the task at hand.
To decide which language to use, you need to consider which languages you know and which language will let you perform the tasks that need to be accomplished in the application. For example, you would not use Microsoft Visual Basic® to develop a device driver. Instead, you would choose a language like Microsoft Visual C++®, as it allows you better access to the hardware than does Visual Basic. You would choose Visual Basic over Visual C++ to create a standard business application because the Rapid Application Development (RAD) environment lets you create this type of application much faster than Visual C++.
When choosing a database engine, you will also weigh certain factors. You need to consider what database engine your client might already have in-house. You might look at how much and what type of data needs to be stored. You also want to consider how easy it might be to integrate with other databases, or to be able to replicate data from one server to another. All of these factors are weighed before you choose a particular database engine.
Although this document will not help you decide which language or database engine you should choose, it will help you make some informed decisions about your user interface. You will go through the same type of decision making when choosing your user interface as you do when deciding the language or database engine to use.
Some choices about the user interface you choose will be very clear-cut. Some choices will not be so clear, and you will have to weigh many different factors before making the final decision. For example, if you are building any of the following types of applications, you will definitely be using a Web interface:
- E-commerce store
- Company Web site on the Internet
- Remote users with no VPN capabilities, but access to the Internet
Likewise, if you are going to be building any of the following types of applications, you will definitely use a desktop type of interface:
- Graphical applications, like games or CAD/CAM
- Word Processors
You'll also be using a desktop interface if:
- You need drag-and-drop support in the application.
- You need to integrate one or more products, like Microsoft Word and Microsoft Excel, with your application.
- You need to integrate with hardware like POS systems, scanners, cameras, or medical systems.
Of course, there are always those applications that don't fall neatly into the above categories. For example, if you are building any of the following types of applications, you could use either type of interface:
- Look-up systems, like product catalogs
- Data entry systems
- Order processing systems
- Accounting systems
- Work flow management systems
- Charting/graphing applications
In these cases, you need to look at many other factors before deciding on which method will suit your application the best.
In this document, you will learn about the advantages and disadvantages of using both of the different types of user interfaces: Web and desktop. Then, you will learn how to weigh other factors that need to be taken into account before deciding on the final user interface (UI) for your application.
When you wish to target a Web browser, it's probably because of the advantages the Web UI brings to an application. Developing with the Web allows you to use standard HTML interface elements. Most potential users are familiar with browsing the Internet and are used to how Web pages look and feel.
You get the benefit of centralized application deployment and upgrading without having to distribute the Microsoft .NET Framework. Instead of having to roll out a new software application (with the large .NET Framework) to hundreds or thousands of desktops, you only need to place the new software on a central server and all users can access the software in one place. Similarly, when it is time to make a change to the system, you only need to make that change in one place. Of course, if your users already have the .NET Framework available on their PCs, then you can deploy Windows Form applications in the same manner across your intranet.
If you have to create an application that remote users can use, it is much easier to export data through corporate firewalls over the HTTP protocol rather than other proprietary protocol.
Some applications take a lot of processing power. Instead of having to update each individual workstation, you can increase the power of your central server. This will be a more cost-effective solution than upgrading hundreds or thousands of workstations.
Of course, developing for the Web is not without its limitations. The same standard HTML elements that are an advantage are also a disadvantage, as they can be somewhat limiting. Elements can appear differently to various users, depending on the browser that is used. This may cause some confusion if users move from one workstation to another.
Another problem with standard HTML elements is that they have no standard way of providing an input mask. A lot of users like knowing the format into which they should enter data. For example, a phone number can be entered in many different ways. In a desktop application, you can specify an input mask very easily; when using standard Web controls, it is much more difficult, as you may have to resort to using script in the client's browser.
You will also have limited control over where screen elements appear on the screen. Standard HTML does not allow for the absolute positioning of elements. This might make your design less elegant than you would get in a desktop application.
Performance can be slower in a Web application because you are sending both the data and the screen design each time you request an HTML document. In a desktop application, the interface is rendered locally once, and just the data is brought across a fast network connection.
It is not easy, with HTML, to go beyond the boundaries of the browser. This means that any integration with other products is almost out of the question. With Microsoft Internet Explorer, it is much easier to integrate than with other browsers, but even then it takes a lot more programming to make it happen. In fact, at this point, you are almost creating a desktop application anyway.
When you program using a desktop UI, you get a much richer set of UI controls than you do with HTML. You can make your UI look like almost anything you want. You can make Tab controls; you can use input masking controls, editable grids, and many other controls that make creating a rich UI very easy. You also have total control over the exact positioning of screen elements.
When creating a desktop application, you can take advantage of the hardware that is already on the machine. You will need to do this if you are thinking of creating a game. Games typically need to interact directly with the video card, which is very difficult (if not impossible) to do with a browser. If you are developing a Computer-Aided Drawing (CAD) or Computer-Aided Manufacturing (CAM) application, you will also need to interact directly with the machine's hardware.
Performance is generally quicker on a desktop because the screen is drawn only once on the desktop and only the data changes. This prevents a lot of screen data coming from the server to the client, which increases the time taken to display the data.
If you need to integrate with any special hardware, such as Point of Sale (POS) systems, numerical control machines, printers, and scanners, it is much easier to produce a tidy interface using a desktop application than it is from within a browser. Browsers are such a closed environment that it is difficult to load the DLL needed to interact with this special hardware. If you are using Internet Explorer 5.x, it is not really that hard, but this does lock the user into using one browser and one operating system.
If you need to integrate with other products, you will find it much easier to do from a desktop application than you will from a browser. Many times you might need to exchange data with Word or Excel. Doing this using automation is very easy in a desktop application, but not so easy with a browser-based interface. The integration process between applications is hard to make generic enough to work across all browsers.
Although you can do a lot with the rich UI support that a desktop application provides, you can also do too much. There are now so many third-party controls available that it is possible to deviate from the Microsoft style guide for Windows applications. If you do deviate from these standards, this can lead to additional training costs, and may cause some confusion when users use a variety of applications in which some follow the standards and others do not.
Desktop applications are sometimes hard to use if the user works from a remote location. Connecting to the main network can sometimes be a problem as users have to deal with dial-up connections, VPN software, firewalls, and a host of other confusing issues.
One of the biggest disadvantages of a desktop application can be felt when you deploy that application to hundreds or thousands of users. Imagine having to burn CDs or setting up a "push" server (like SMS) to distribute an application to that many users! This can be quite a job. And each time you have to do an update, you have to do it all over again. Of course, .NET can help because it is now possible to push desktop applications across HTTP just like Web applications.
If users move from one workstation to another, they have to worry about whether or not the application is installed. Also, if one user sets up their machine with different colors, different Start bar location, or other "preferences," another user trying to use that machine will have a more difficult time.
Now that you have learned the advantages and disadvantages of designing your application using a Web or desktop style, let's take a look at some other factors you will need to take into account.
As you read the various factors in the primary and secondary questions, keep track of how many "Yes" answers you get, scoring 1 point for each. You'll deduct the total score of the secondary questions from the primary questions. If, after you have worked through both lists you have a fairly high number relative to the total number of primary questions, you should probably develop for the Web, and vice-versa.
|Question||Score (1=yes, 0=no)|
|Are your users comfortable using a Web browser?|
|Are your users located in remote sites?|
|Do your users in remote sites have access to the Internet?|
|Are you creating a Business to Business (B2B) application?|
|Are you creating a Business to Consumer (B2C) application?|
|Is the amount of data entered minimal?|
|Is the amount of data to display on the screen minimal?|
|Is the number of fields on the screen fairly small?|
|Does each user "own" their data?|
|Are the same rows of data rarely updated by multiple users at the same time?|
|Is this application mainly for light data entry, where speed of data entry isn't critical?|
|Is there a lot of data review that requires "tall" pages?|
|Do your users like to scroll through the data, as opposed to tabbing through data?|
|Are there minimal data items on a screen that cause other data to change on that same screen?|
|Can your users minimize the need to exchange data dynamically with other products running on the same desktop?|
|Is performance a secondary consideration?|
|Do your developers (or you) want to develop for the Web?|
|Do your developers (or you) have the skills to develop for the Web (or can they quickly learn how)?|
|Do you want a very graphically appealing look and feel?|
|Do you have a lot of large screens that would warrant scrolling windows?|
|Is it important to keep deployment costs to a minimum?|
|Is it important to keep upgrade costs to a minimum?|
|Will there be frequent updates to software?|
|Can you hire/train Web programmers more cheaply than desktop programmers?|
|Do investors and/or shareholders want a Web application?|
|Would your users prefer a browser interface to a desktop application?|
|Do users in remote sites have a high-speed connection to your internal network?|
|Is it fairly easy to install Internet access in remote sites?|
|When your users travel, do they usually have access to the Internet?|
|Is this application only for one department?|
|Subtotal for Primary Questions|
|Question||Score (1=yes, 0=no)|
|Is there a need to connect to special hardware?|
|Do you need Drag-and-Drop support in this application?|
|Are you designing a game, CAD, or CAM application?|
|Do you need a lot of special controls for limiting data input (such as input masks)?|
|Can deployment of this system be done through a network, by distributing CDs, or using push servers?|
|Can upgrades of this system be done through a network, by distributing CDs, or using push servers?|
|Subtotal for Secondary Questions|
Now Do the Math!
|Subtotal for Primary Questions|
|Deduct Score for Secondary Questions|
A higher score leans toward developing a Web application, and a low score leans toward developing a desktop application.
The lists above should be used as a starting point. You may wish to add additional questions depending on your particular situation
There are many factors to consider when choosing the best method of development for a particular project. Even after weighing all of the alternatives, you may still decide you could go with either one. If that is the case, you might just wish to choose the one with which you and the users are most comfortable. If you are in doubt, ask your users which they prefer!
Paul D. Sheriff is the owner of PDSA, Inc., a custom software development and consulting company in Southern California. Paul is the MSDN Regional Director for Southern California, is the author of a book on Visual Basic 6 called Paul Sheriff Teaches Visual Basic, and has produced over 72 videos on Visual Basic, SQL Server, .NET and Web Development for Keystone Learning Systems. Paul has co-authored a book entitled ASP.NET Jumpstart. Visit the PDSA, Inc. Web site (www.pdsa.com) for more information.
Informant Communications Group, Inc. (www.informant.com) is a diversified media company focused on the information technology sector. Specializing in software development publications, conferences, catalog publishing, and Web sites, ICG was founded in 1990. With offices in the United States and the United Kingdom, ICG has served as a respected media and marketing content integrator, satisfying the burgeoning appetite of IT professionals for quality technical information.
Copyright © 2002 Informant Communications Group and Microsoft Corporation
Technical editing: PDSA, Inc. and KNG Consulting