Differences in building UI between Web and Desktop Applications [closed]

L

7

5

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

Leasia answered 5/12, 2008 at 14:45 Comment(1)

Interesting read here: Web Apps vs. MS Windows Apps. – Sycamine 5/12, 2008 at 14:49

S

6

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)).

Sweetener answered 5/12, 2008 at 18:37 Comment(0)

T

7

One major thing you can't ignore in Web Design is the back button. Thousands of people have tried to disable, or get around it. Don't try to get around the back button! Instead make the back button part of your design.

Treviso answered 5/12, 2008 at 14:48 Comment(0)

S

6

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)).

Sweetener answered 5/12, 2008 at 18:37 Comment(0)

T

3

The single biggest difference is IMO that in a web app, you have very limited influence on mouse behaviour, and what you have runs counter to established desktop behaviour. For example:

In desktop apps, a right mouse button click almost universally results in context menu popping up. In a webapp too, but it's the context menu of the browser, which you cannot (and should not) change.
In desktop apps, a single click selects something, a double click executes something; in a webapp, a single click already "executes" a link, and double clicks do not exist.

Tannen answered 5/12, 2008 at 14:53 Comment(1)

You can override the brower's right click. Google Docs does it quite nicely but allows Shift + Right Click to pull up the browser's menu. Which makes the overriding somewhat acceptable. But, as far as I know, Google Docs is the only website that provides a way to get at the browser's context menu – Treviso 5/12, 2008 at 15:13

H

2

Desktop apps tend to be written using an "on this event execute this block of code" pattern. Web apps are more block mode "server formats a whole page, user fills in form and presses button, server processes whole form, server formats another whol page" pattern.

AJAX muddies the water slightly because the browser can request some data in the background, and, refresh parts of the page. However the basic principle remains.

It is easier to make desktop GUI respond to particular mouse movements and clicks etc. For Web apps on the other hand the only communication with the server is "get" and "post" requests so the user interface is much clunkier.

Web based apps is are much more portable and you only software you need on the client is a compatable browser. These system management advantages are why people put up with slightly inferior GUI.

Haematopoiesis answered 5/12, 2008 at 15:3 Comment(1)

Although the answer is from 2008, the single biggest drawback of desktop is as you mentioned - "Desktop apps tend to be written using an "on this event execute this block of code". That results in business logic ending up in the client. – Nakano 18/5, 2015 at 8:28

H

1

The major difference is the Visual is really fast on a Desktop to build and no need to test with different browser.I always found a charm to build desktop because Visual portion of the software just bind on your controller (that contain your model) and you are on a go!

An other difference is the loading speed. You do not have to transfer Javascript or CSS for the display... You do not have to zip or other thing because it's always available in the source code on the desktop.

Other thing is that you can use the RAM of the computer to do hard thing and this tend to reduce the need to have multiple computer on the service side because you can use all those computer to "farm" big process (if needed).

On the other hand, deployment is harder (well you have ClickOnce and automatic tool that can help you), but it's never as transparent of web. So, you have to be more planned to do release because you cannot do "hot fix".

Hydrobomb answered 5/12, 2008 at 15:14 Comment(3)

You may not have to test with different browsers, but you still have a number of operating systems to test desktop apps on. XP, Vista, 32 bit, 64 bit and all using different languages. – Gemagemara 5/12, 2008 at 15:28

Testing different browsers couldn't be easier. On Windows you can test IE, Firefox, and Chrome and you have covered most of the browsers out there. Chrome uses the same engine (Webkit) as Safari. – Treviso 5/12, 2008 at 15:34

By experience, I tell you that testing for browser is MUCH more pain... your web application still need to be tested in all OS too.. And 32bits to 64bits is a 99% only 1 setting to change in the compile.. not a big deal. – Hydrobomb 5/12, 2008 at 18:46

W

0

Cross frame communication is difficult in a web browser. For example having one iframe influence another iframe with javascript. Primarily because the load times may be different, so frame A may need to wait on a timer loop for frame B to load.
In a web UI, messaging really needs to take the request/response cycle into account. Its hard to do something like "if a record changes int eh database, pop up a message ont eh users screen". Also, if pressing a button has to refresh 5 different iframes, you may end up with 5 seperate requests to the server. Don't really need to worry about that in a desktop UI.

Winthorpe answered 5/12, 2008 at 15:18 Comment(0)

G

-2

The one thing I found most different is data binding. The concept is still the same, but with web apps, you're always worried about whether or not to rebind said control to refresh the data based on some other event click. The nice thing about desktop apps is that this is that this isn't as much of a concern, since clicking some other event, or going to some other tab isn't going to invalidate the data in a control.

Goon answered 5/12, 2008 at 15:23 Comment(0)

Recommended topics

Hot tags