Differences in building UI between Web and Desktop Applications

Question

The UI for web apps is constructed differently from the UI of desktop apps. I'm interested to know what are actually the major differences in building UI between the two styles of applications in the following areas:

1.Technology used

2.Techniques used

3.Controls used

4.Screen changing behavior

Answer 1

A big design difference that a lot of people overlook is the structure of the window itself.

• A desktop app tends to be built for a minimum height & width resolution (often 800*600), and tries as hard as it can to fit all the relevant information into a size smaller than that, because scroll bars are generally very bad practice for non-tabular/list data. Where more space is needed, the information is generally split into either new windows or sub-window panes/tabs.
• A web app, on the other hand, has essentially infinite vertical height, as most people are used to scrolling in their web browser. The scroll bar is no longer a bad thing; in fact, using a scroll bar anywhere where the main one could be used is usually considered bad form (with a few exceptions, of course). Information is typically portrayed in one 'window', as splitting it up would require both separate page loads, and re-loading identical data (styles, menus, etc. yes, there's a cache, but it's not as fast as not loading a single page). More loads are always slower, and cause feelings of discontinuity. Sometimes they're inescapable, but you should almost never constrain your app to only the visible size of the browser window.
• A lot of what people use a web browser for is reading. News, blogs, comments on youtube, etc. When you make a web app, it should reflect this habit, because you will otherwise jar people's brains through wildly different layouts if they're switching between web pages and your app (and you know that some will). It may seem like you're just copying the big players, but consistency is much more important than it immediately seems.
• Columns of text shouldn't be super-wide, because the wider a line gets, the harder it is to jump to the next line to continue reading. Stick to something similar to what books have; they've been refined for centuries. This is part of the reason why a lot of web pages are fixed-width, and favor columns over rows.
• White space is important. It helps separate information, and makes it easier to process. Imagine reading this reply without any spaces, new lines, or bullets.

A pet peeve of mine are text links that perform frequent actions. Unless you're actually 'linking' to a separate page, do not make it look like a link. Make it a control, or an image, or something. Links are for moving in websites, buttons do things. Most people will actively ignore blue, underlined text when they want to do something, because they're used to a "submit form" button, or something similar. Links are also quite small and comparatively difficult to click for repeated actions, and for me reek of incomplete design/coding when used extensively.

A lot of web apps that I've seen that have generally failed try to duplicate a desktop app in a browser window... which is fitting a round peg into a square hole. It can be done, but they are not the same thing, and should not be treated as such under almost any circumstance.
A partial exception is when the web app duplicates the function of a desktop app (ie, Google docs). Then, the layout should still reflect a web page more than an app in most circumstances, but the controls should probably mimic a desktop application to help people transition.

Most people use programs on their desktop to do something. Most people use their browsers to see something (read, watch, etc). Of course, there's crossover, but think about most people's daily habits, and remember that other people will be using something you design; it's not just you (and your clones) out there.

And, though it's repeating others, the back button is critical. If you break it, users will want to break you. Overriding the right-click menu or behavior is also usually a bad idea, and mostly annoys users (and some will actively prevent javascript that does this because it annoys them so much (myself included)).