Developers who are used to working with desktop applications often find it difficult to transition to Web-based application design. The lack of designers throws them for a loop and, fixated on control positioning, the developers find it impossible to create compelling user interfaces. Here are five suggestions to improve the design of Web interfaces that work on any device.
When you work with desktop applications, you assume the user has hardware capable of displaying windows in a certain way. As a result, you develop applications with windows of a specific size where you position controls in a particular way. The display looks exactly the same to each user because the developer controls the display environment to a high degree.
However, most Web-based applications don’t behave in this manner. The fluidity of Web-based application design causes considerable angst for many desktop developers. In Web-based application, a developer no longer has control over the hardware’s display characteristics, and neither does the user. The display characteristics are under the device’s control, so a developer really can’t control the look of an application any longer.
Before you start a writing campaign: Yes, I realize it’s possible to force the desktop browser environment to present Web-based applications much like desktop applications. Using fixed measurements may not provide the developer with total control, but the effect is similar to the desktop—making the desktop developer sigh with relief.
Unfortunately, this approach is a dead end. These applications won’t work right on other devices such as smartphones and tablets. You need to create applications so they run well on any sort of device, which means embracing Responsive Web Design, not running from it.
Developers can become even more uncomfortable when working with IDEs designed for Web-based application development because these IDEs often lack any sort of designer. These IDEs contrast with products such as Visual Studio where you can drag and drop controls onto a form, set the particular details of each control, and then run the application to see a functional replica of the designer interface.
However, the lack of designers in these IDEs isn’t a concern because a Web-based application doesn’t have a specific appearance; it looks different on each device category that runs it. You simply specify that the application requires, say, a drop down list box to display a list of countries as part of an address entry. The position (and to a degree, the size and appearance) of this control isn’t a concern.
With the fluid nature of Web-based applications in mind, the following sections help you gain some level of comfort when working with the new design paradigm.
Focus on Content Presentation
Developers easily can be distracted by eye candy. An application is supposed to manage data, to ensure the user can perform Create, Read, Update, and Delete (CRUD) operations without problem. When a developer’s attention is on placing each control in a specific location on the window, less time is spent focusing on the content. By removing precise positioning from the developer’s control, Web-based applications actually make it easier for you to focus attention on the content, which is the main reason to develop the application in the first place. Besides, you may come up with unique methods for ensuring the user inputs the right sort of data and in the correct range, based on the available control types.
Assume that Users Employ a Range of Devices
Desktop applications are becoming less popular for a good reason: They’re inflexible. Users begin their day by using your application on their smartphone, move to a tablet, and then finish a task using a laptop. It’s no longer a matter of assuming your user is looking at a particular display; it’s a matter of the user looking at every conceivable display, and expecting consistency across the devices.
Fortunately, Web-based application technologies are designed to automatically compensate for device differences. A user with a small screen simply sees less of your application at any given time. In addition, you only need to check one or two representative examples of a particular device category to know that the application looks right on all devices in that category. In most cases, individual device testing isn’t a requirement.
Because users can employ just about any device, your Web application will see more use and become more popular. Creating a popular application translates into job security and greater satisfaction with the application you create. In short, focus on the fact that your application needs to be flexible in order to attract the right sort of attention.
Order Content in a Logical Manner
Many desktop applications don’t order content in a logical manner because the developer was concerned with creating a pretty interface, rather than a functional interface. Consider the design issues in the Windows 7 calculator. Microsoft managed to take a functional application and turn it into a nightmare of dysfunctional pieces that don’t work well together.
As you start designing Web-based applications and recognize that users rarely see everything at once, you begin to start thinking in terms of workflow. Each application element needs to move the user through a given task no matter what device the user chooses to use. The applications you build start to order content in a logical manner because – I assure you that you will find – no other arrangement works. As you use the application on various devices, the best way to order problems become a lot more obvious.
Develop Individual Input Checks
One problem with moving from the desktop to Web-based applications is one of ensuring data integrity. You must learn to provide individual input checks for each piece of content because it’s no longer possible to know when the user will move from one screen to the next; each device displays a different number of controls per screenful of information. This is actually a positive change for developers, as the requirement helps reduce the probability of bad data getting into the database.
There are a number of schools of thought with regard to input checks. Most developers use JavaScript client-side checks to perform the initial check and then perform a secondary check on the entire page at the server. The reason for two checks is that some people try to send damaged, incorrect, or incomplete data by circumventing the JavaScript check. I recommend you use the client-side check to make the application faster.
Newer applications rely on Asynchronous JavaScript and XML (AJAX) to send just the changed data to the server as the user works with each control. This approach reduces the time required to send and receive the data, which makes it possible to use just one check for each bit of content. Some libraries, such as jQuery, make the task of using AJAX significantly easier.
No matter what approach you use, it’s important to provide feedback to the user as soon as an error is detected. If you wait until all of the data for a page is collected, the user may actually have to page back several screens on a smaller device to fix the error (potentially causing yet more errors).
Reduce Complexity
Complexity is the enemy of Web-based applications. Small devices, such as smartphones, will be used to interact with your application. So, anything you can do to clean up an interface is good.
Begin your cleanup by looking for unnecessary input. For example, when presenting a list of possible choices, with a final choice of Other, don’t ask the user to type in what the other choice is. In most cases, the information doesn’t do your organization any good (Does anyone look at that data? I doubt it). Plus it causes some users to stop entering the information. Amplifying information is great as long as it’s needed, but in most cases, it really isn’t necessary.
Automate as much input as you can. Whenever possible, provide default information to save typing. For example, rather than ask a user to input complete contact information each time, bring the information up automatically using information found on the server. A user’s e-mail address is all that you really need unless you’re interacting with a new user. Better yet, query whether the information is actually needed; in some cases, you’ll find that it isn’t.
Typing is problematic on small devices. Provide as much input using non-text input as you can or reduce the typing when you can’t. For example, rather than type the name of a state, provide a list of states in a drop down list box. Better yet, ask the user for a postal code and look up the information using any of a number of free Web services. Enter the city and state based on the postal code whenever possible. (The user would need to enter the postal code anyway, so entering it first makes sense.)
Bottom Line
Developing an interface for Web-based applications is different from developing interfaces for desktop applications. In the first case, you have significant flexibility and can focus solely on content management. In the second case, you have total interface control and need to consider issues such as control placement. In the grand scheme of things, the Web-based application is actually easier to design. More importantly, it helps focus your attention where it needs to be focused: on the content.
See also:
[dfads params='groups=932&limit=1&orderby=random']
[dfads params='groups=937&limit=1&orderby=random']