Fog Creek Software
Discussion Board

Web UI vs Windows UI

A thread here sparked a bit of a issue of the web vs windows.

(the share cropping topic).

In other words, the web is really not that good from a UI point of view, but it’s incredible successful despite this. In fact, the argument goes that the web’s simplicity is it very advantage. You can just whack the back button.

No software installs, less training. Etc.

When you look at the success of browser, it is certainly hard to argue. I mean stuff like hotmail, and even data searching stuff like yahoo and googole are simply mainstays. While there are successful windows email clients, I can’t think of any "search engine" portal that runs on windows that connects to a server.

It would seem that despite all those cool technologies like Java and the windows forms for .net, the simply browser remains the king of the hill.

Further, it seems when you give a customer choice between a thick windows client VS a browser based product, the browser wins hands down. This is despite the lack of a quality interface. As mentioned, this simply is the very nature of the browser.

So, question time:

If one can, should one use a browser interface over that of a rich windows interface?

Note that we also need to break down the type of application.

General data entry,
database searching etc,
and then the last one:

of word processing, or manipulation of data. It would seem the last one, paint programs, word processing, Excel, etc is much better when the brain needs to connect to the application in a artistic way, or a creative way.

However, for the rest of the stuff (boaring data entry), it seems compelling to use the browser.

The major downfalls of the browser is that the application in question needs a live connection to the web.

However, so did green screen appcltions of many years ago. Connectivity is a real key here.

So,  as connectivity continues to improve, should we dump the rich windows interface in place of the simple browser?

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, July 14, 2003

The success of web UIs has nothing to do with the "simplicity" of the web (it's not at all simple if you want to support many browsers across many OSes). Web apps exist in spite of their clear inferiority to rich apps for one single reason: a heritage of IT control over applications that's much, much easier when the application is web based. IT can deploy versions quickly and easily, both rolling forward and back as needed, without regard to the state of or quantity of desktops.

.NET can eliminate most (if not all) of these complaints, if your target audience is Windows users with the .NET Framework (perhaps a reasonable requirement for a corporate application). Assuming a continuous live connection -- which you have to assume for a web app -- you can make some seriously power client/server apps in .NET that require no installation, with upgrade scenarios on a par with web applications.

Brad Wilson (
Monday, July 14, 2003

Brad, The original sharecropper article says simplicity is on the side of the users, not the developers.

Monday, July 14, 2003

I think webUI are often preferable. One thing that has bothered me about them in the past though, is the inabliity to do local saves in a consitent fashion.
This is why I got so curious about HTAs (A few threads back)

I did a database for a medical reseach institution for storing test cases. Each case typically had 10 pictures and some 5000 words of text to be entred into some 20 textboxes. Not very smooth. I offred to write a VB app where the user could compile the case and store it locally, and then upload the entire case to the DB when it was done, but they rejected that option for various reasons.

HTAs provide an easy method to insert this capabillity in what is essentially still a web app.

The request-response mechanics, and lack of state of HTTP can otherwise make entry of large and complex datasets really....weird.

Eric DeBois
Monday, July 14, 2003


Reminds me of Paul Graham's article which mentions why web based software is more advantageous, I am guessing the same reasons apply here.

Prakash S
Monday, July 14, 2003

This is the quote:

"Web pages weren't designed to be a UI for applications, but they're just good enough. And for a significant number of users, software that you can use from any browser will be enough of a win in itself to outweigh any awkwardness in the UI. Maybe you can't write the best-looking spreadsheet using HTML, but you can write a spreadsheet that several people can use simultaneously from different locations without special client software, or that can incorporate live data feeds, or that can page you when certain conditions are triggered. More importantly, you can write new kinds of applications that don't even have names yet. VisiCalc was not merely a microcomputer version of a mainframe application, after all-- it was a new type of application."

Matthew Lock
Monday, July 14, 2003

The web has flourished despite the user interfaces it provides, not because of them.

In a vast majority of cases, I view the "simple" user interfaces in web apps as slow, clunky, and feature-challenged.

Monday, July 14, 2003

Many applications offer a Web UI in addition to (not instead) a desktop client UI.

Christopher Wells
Monday, July 14, 2003

I think in general Web UIs look better than Windows UI.

Windows UI tend to be very utilitarian, with grey boxes and dull labels.  Very little in the way of colour.

Just compare the Citydesk screen shots with Fogbugz:
Nice tables and colourful headers.  Their is no separation between content and controls.  I click on a hyperlink to go deeper.  It is clear what actions are available at this point in time.  The whole page is present as a single whole.
Ignoring the HTML preview, which stands out because it is more attractive than the rest of the page, the buttons and tree views are all of a regular, repeated pattern.  The icons are all the same size and somewhat abstract.  Everything is on a smaller scale.  The elements are separate and abstract - menu bar, icon bar, content.

Of course, the trade of is the flexibility of the interface.  With the Windows GUI you have menus, icons, right clicks, drag and drop. 

However, the web interface is much closer to the printed page, which is more familiar and inviting to the average user.

Personally, I think the current Windows UI will disappear as the Web UI matures.  A few years from now the style of windows interface we are used to know will look as old and clumsy as the text interfaces of Wordperfect and 123 look to us now.

Ged Byrne
Monday, July 14, 2003

Just to clarify, I'm talking about the means of presentation rather than the delivery method.

I'm sure http and browsers will disappear to.

Ged Byrne
Monday, July 14, 2003

"Web apps exist in spite of their clear inferiority to rich apps for one single reason: a heritage of IT control over applications that's much, much easier when the application is web based."

Which is why Amazon, Google, eBay, Yahoo, HotMail, etc. etc. use the web browser for their interface? 

Jim Rankin
Monday, July 14, 2003

"Windows UI tend to be very utilitarian, with grey boxes and dull labels."

Just so you know, this is totally different on the Mac.  On the Mac, instead of "grey boxes and dull labels" we have "METALLIC grey boxes and PIN-STRIPED ANTI-ALIASED dull labels."

We also have "lickable" window controls, but those seem to be going away because of issues with Mac users and monitor hygiene.

Jim Rankin
Monday, July 14, 2003

I'm currently building a Windows app with HTML UI.  The reason is simply that people are so used to the way Web UI's work (single click links, forward-back concept, etc) that it makes sense even for desktop apps.

There are certainly some limitations, but since I'm tied to only one browser (IE), I can use lots of cool widgets to make up for those limitations.

I'm pretty sure that both Quicken and Money also use embedded HTML interfaces.

Monday, July 14, 2003

Yes, MS Money's UI isn't too far off from HotMail's UI. Though, both of them being MS products, they use a few more IE specific tricks than most other web sites. Though Hotmail looks just fine in Firebird.

I'd like to know what everyone thinks is inadequate about the web's UI. Using DHTML, CSS, and JavaScript, it's become closer and closer to the Windows UI. Add in the occasional Java applet and you have something that you would almost swear WAS Windows.

Spreadsheets are a good example of something that probably works better as a Windows app than as a web app simply because of the quantity of information being displayed - thousands of datapoints that the browser simply isn't capable of updating in real time like Excel can.

For 90% of user's tasks though, the Web has a UI that works.
Monday, July 14, 2003

Why does FogBugz have a "insert picture of bunnies" feature?

Monday, July 14, 2003

It does seem that the web stuff in general looks more like printed material.

Perhaps in a short time, we will not be able to tell the difference between web stuff, and windows....

The web is influencing the look of windows software.

The problem is that some of these large companies do a ton of usability testing. The result is not the best UI, but perhaps one that is easier to use, and that seems to be why the web is influencing programs like money.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, July 14, 2003

At work I'm responsible for recruitment. I spend from seven to ten hours a week answering emails, entering data into a Access database, and storing associated files.

When we're on holiday I have got web access to email through Outlook web access, and it would be trivial to set up web access for the database. I don't even mind giving up the time too much, as the work only accumulates if I don't do anything.

I found out last year that working over the Internet was tripling the amount of time involved. I was waiting ages to download the attachments, and it was impossilbe to keep track of the conversations. The Contacts folder has 2450 entries and takes up 125 web pages; the messages are all kept in a large folder that has 14,000 messages at present, and would take up 600 + web pages. In practise I was keeping a copy of everything locally and emailing new copies of the database to the secretary to put on the server. After ten days I gave up, and this year I'm not even trying.

And I don't know how many more times this has to be said but standard Windows forms are a subdued color because they are for applications, which users will be seeing for hours each day, every day. Bright colors, bold buttons and even colored scroll bars would soon get on your nerves.

Stephen Jones
Monday, July 14, 2003

I've been developing for the Pocket PC  the latest months. The differences between the Pocket IE and the native windows UI showed up clearly. Partly this was due to PIE being such a bad copy of Win IE. But I found one interesting hybrid class of browsers, driven by xml. The most promising attempt is Thinlet, a browser applet in a browser, written in Java, accepting form definitions and Java code. See
The interesting part in this for me is the possibility to get new apps (forms+code) to the Pocket PC without installation. And this works on the PC as well of course. Another important issue is the amount of band width used over gprs on pocket pc. Using compressed xml you can express the same functionality as up to ten times more html code. And we all know what a byte waster ASP.NET is.

Christer Nilsson
Monday, July 14, 2003

Most users don't like setting up their computers.  Hence, a web app wins almost every time.  They just remember a URL (or email it to their web-mail account), and they can use the app from anywhere they may happen to be.  They never learn the power-user functions anyways, so all the keyboard shortcuts and rich features of a client-app go unused and unnoticed.

I think client apps will be more and more focused towards the power user as time goes on.

Richard Ponton
Monday, July 14, 2003

The biggest advantage I see with web UIs is the ease of creating attractive interfaces.Compare the effort it takes to write HTML to display some text, images, and maybe some text fields - perhaps a couple of minutes for a proficient HTML author - to the effort it takes to write the equivalent program in MFC, VB, GTK, Java, etc - at LEAST an hour, probably more. Now consider that the web version will display on (almost) any web browser on any platform, but your MFC/VB version will only work on Windows, and your GTK and Java versions will look like crap on most platforms.

What this tells me is that there must be a better way of writing non-web GUI applications. There has *got* to be a way to write Win32/Mac/Java GUIs that is as simple as HTML. Of course you'd be missing the really advanced widgets not available in HTML, but boy would it be nice to bang out a simple dialog box in two minutes rather than two hours. (I haven't learned much about .NET but I suspect it's a step in this direction...)

The biggest problem I see with web UIs is latency. It takes several seconds for the request/response to do simple things like call up my next message in Yahoo mail. But for non-critical or occasionally-used apps, the latency problem is not a big deal.

Dan Maas
Monday, July 14, 2003

If you want a dirt simple way to bang out dialogs quickly, check out TCL and the TK toolkit. This is a scripting language with a very fast way to create dialogs, and it handles all the resizing automatically.

The problem is that TCL falls down in building full applications.

Chris Tavares
Monday, July 14, 2003

We labored over this decision for about two months when we decided to move our Microsoft Access-based vertical market application to .NET.  For what it's worth, I've listed below some of the reasons we chose to go with a Windows Forms implementation.

I'm sure there are ways to work around some or all of these things in a Web-based UI, but there's only so far you can go before you're simply trying to work around the limitations of a technology instead of using the technology that's best suited to the problem.

1. Drag & drop. We needed to support drag & drop operations both within the current window, as well as between windows when the user opens two instances of the application and looks at two different files.
2. Rich UI.  Although this is a client-server application, it makes extensive use of listviews and treeviews. In addition, there is a lot of information to fit on the screen and only because of the level of control the Windows forms UI gives us can we succeed in tailoring the user experience so it works exactly the way we want.
3. Modeless dialogs. In some areas of the application, we use modeless dialogs in a "toolbox" fashion, allowing the user to move the dialog around on top of the application.
4. Microsoft Office-like UI. One of our selling points is that the application is familiar to those users currently using a Microsoft office application.  I.e., the menu bar & toolbars at the top of the screen, etc. Our number one competitor is Microsoft Excel, so this helps during the sales process.
5. Calculations. Our application has some accounting application-like functionality, which makes it a great candidate to take advantage of the processor on the client computer to perform calculations as the user is modifying information, then save the changes to the database once they're finished.
6. Creating combo box entries on-the-fly. This is a function point we use throughout our application. The user types an entry in a combo box that doesn't exist and forces the focus off the control. The system pops up a dialog for the user to confirm the entry.

This is just a sampling; there were a few other reasons. The bottom line is that to get the application look and feel the way we want, although certainly possible in a Web UI,  would have been a lot more difficult, and the result wouldn't have been EXACTLY what we wanted for a user experience. Plus, with .NET's XCopy deployment as well as its ability to dynamically retrieve assemblies from a Web server, largely eliminate the major issues relating to distribution of a Windows application.

Monday, July 14, 2003

This is definative, so don't read it and then post some lame reactionary critisism, read, think, accept, and move on.

Web pages own the farm for simple content delivery because they are easy to create and flexible.

The sheer number of people who are creating their own webpages is amazing.    The fact that so many different types of webpages have been created is amazing.

Web pages have made massive inroads into being used as fully fledged 'applications' because they own the farm for simple content delivery.

Closely examine the emotional response of an accountant or doctor or school teacher or your average IT illiterate IT CEO to the following two sentences.

"Just install it off this cd, configure it and run the application, there is a help option" 

"It's on the web.  Go to and login."

People are comfortable with the web, it's easy, they know what to expect.  Stand Alone applications are an inconsistent, hard to configure mess that bring fear and uncertainty to the hearts of those who have to install configure and use them but don't actually have the knowledge to control them.

"But IT departments install and configure, but applications have very simple and intuitive setups, but..."


It's always about people.

Monday, July 14, 2003

While there are successful windows email clients, I can’t think of any "search engine" portal that runs on windows that connects to a server.

I can.


Tuesday, July 15, 2003

I'm surprised more people haven't mentioned perceived performance as an issue with web-based UI.

As a user of various applications, my biggest gripe about HTML-based interfaces is that they are often maddeningly slow to use compared to applications that run locally. You click on an object you want to work with and then hear the annoying "you just clicked on a URL" sound, then wait for the app to make a round trip to the server to pull down your requested info, followed by a page's just not "snappy" compared to traditional applications.

I once pulled out my trusty stopwatch and timed an app that I perceived as egrigously slow and was surprised to note that the perf didn't seem that bad from a technical point of view - maybe 1 to 3 seconds to sync the UI with each click. But that slight delay (plus that annoying "click" sound!) just added up to a frustrating experience.

I always prefer a locally running application to a web based UI, and the perceived responsiveness is probably the biggest reason.

Mike Treit
Tuesday, July 15, 2003

As someone who's developed both, I find it unbelievable that people can say that web apps are easier to develop. They're a heck of a lot harder to develop quickly. I mean, you can mention MFC, but damn, MFC is a horrid example. I bet a good Delphi programmer can get a working UI prototype up and running a lot faster than a good web programmer can.

Then there's the fact that the Delphi programmer will be able to actually do things in minutes that as a web programmer you're left spending days hacking around because the web simply wasn't meant to do, but some bozo in a suit demands the app do.

As far as usability goes, as soon as the app gets complicated, the web loses out. For something simple like this forum, it's fine. When you're dealing with large amounts of data, or heirachical deeply nested structures, or whatever, you have to cludge like hell with the web to make it both reasonably fast and still usable.

It also depends on your target audience. If you can rely on everyone having, say, ie 5.5 or greater installed, then no problem. But if you have to support the "browser" in general, then as a developer that's a much bigger PITA than supporting different versions of windows ever was.

As far as "just insert this cd and install goes", that's pretty much bunk. You can make an app that sits in a nice self contained directory, doesn't need an installer (although you'd probably provide one because that's what people expect), automatically updates itself, and so on. Companies get away with not delivering that sort of experience though because people expect too little from their desktop apps in terms of ease of management.

Web apps have their management downsides too - if the network goes down (or you're out of the office and just dont have access to it), you can't do anything, for example. So you're tied to being online, even if the particular piece of functionality doesn't require any connectivity. I dont really consider that a desirable property.

Even in terms of consistency, if you picked 10 windows applications at random, you'd almost certainly find more in common between their UI than 10 web apps. You can hardly say web apps are less complicated, since they all invent their own interface, right down to the colour scheme.

From both a developer and user perspective, I'd take a desktop app over a web app just about every time. The only exception is for an application that offers simple and by necessity connected functionality (like forums).

And the horse you rode in on
Tuesday, July 15, 2003

Lets compare apples with apples.

How long would it take to develop a thin-client server, massively scalable, platform independant, non-installed, multi-user, rich media application that was optimised for low bandwith networks?

Because you get all of that for free when you build a web application without writing a single line of code.

Matthew Lock
Tuesday, July 15, 2003

The point Matthew is that the low bandwidth is what makes the web based interfaces unusable in many cases.

Our college network is fibre-optic ATM up to the wiring closet. Working from the server drive is the same as working from the hard drive in terms of speed.

The connection to the innternet is a 256Kb leased line for the forty or fifty staff with an internet connection. The students have another leased line.

So if I call in from outside at say the 40-45kbps my modem seems to connect here from Lanka, I will be taking up a quarter of the whole available server bandwidth. And just opening the email attachments will take up that time permanently for maybe an hour a day.

Web apps are not good for someone who is working with data on more than an occasional basis. WTS does appear a much better way to go.

Stephen Jones
Tuesday, July 15, 2003

"We also have "lickable" window controls"

I can imagine web browsers could find a use for those on certain kinds of websites.

Tuesday, July 15, 2003

"You can just whack the back button."

For an e-commerce app we wrote for Worldcom a few years ago, whacking the back button brought chaos.

We had to build a system that had a "rich UI" but built with HTML & JSP code on the front end and Java Servlets on the backend.

Because of user expectations (they wanted all the features of a Windows GUI but through a web browser) plus they wanted support for several versions of Netscape and IE; all of which had their own incompatibilites, even between pint release versions. 

On top of all this, we had to write our own code to manage states, and that back button was the killer.

Having done both rich UI coding in Windows and web programming, I can see the advantages of both - but you need to write generic UI code (and scripts) that will work easily in all browsers.

Brad Clarke
Tuesday, July 15, 2003

Matthew, I'm sorry but your statement is just silly.  Of course the web will win out in your example if you cite only the things the web was designed for.

I could just as easily turn it around and say "how long would it take to develop a UI with rich interface, fast response, access to a wide range of PC hardware, that can be use offline?  Because with Windows UI you get all that for free."

Both have their strengths.  Personally I think Web UIs are overrated.  I've never used one of any significant complexity that I thought was good enough for regular use.  The latency issue for one is just too significant.  Not to mention the problems you have with trying to keep transaction state.  And anyone who talks about how with the Web UI you get support for every browser, I call BS.  It is far harder to design a web UI that will work well and consistently for all available browser, than to design a Windows UI that will work well and consistently for all versions of Windows.

Mike McNertney
Tuesday, July 15, 2003

"Brad, The original sharecropper article says simplicity is on the side of the users, not the developers."

I only agree that simply web content is simple for end users. Complex applications in web browsers are pretty much always frustrating, time consuming, and fraught with the kind of bugs you just never see with traditional UI applications.

I'm not saying rich UI is perfect, but from both the end user and the developer point of view, there is a lot more capability to be had, a lot easier.

Brad Wilson (
Tuesday, July 15, 2003

Hey hey, Flash MX, both worlds, Web UI benefits, getting closer to a Windows UI. Watch out for this on!!!

Some sam
Tuesday, July 15, 2003

It's dead easy to develop for all available browsers providing you stick to HTML. It's when people use the kewl javascript and DHTML tricks that causes incompatabilities.

Matthew Lock
Tuesday, July 15, 2003

Unfortunately, many users demand that you do things that require you to use JavaScript and DHTML.

If your point is it's best to stick to plain HTML, I agree. But only with the proviso that as soon as HTML can't cut it, you scrap it and write a desktop app rather than trying to extend the web app with JavaScript and DHTML.

And the horse you rode in on
Tuesday, July 15, 2003

Most of the time Javascript is only demanded for form verification or DHTML menus or rollovers. In the first case server-side validation is more secure and robust, and in the second case the application can be coded so that if the menus or rollovers don't work the application is still functional.

Matthew Lock
Wednesday, July 16, 2003

If your target is not exclusively Windows, look at the Mozilla platform (the new one that Firebird is built on). It can mix HTML XML and rich cross platform widgets all styled with CSS and scripted in javascript. It can be installed locally or run remotely and has javascript APIs for http, XML-RPC, Soap, WSDL, local file access etc.

The 'back end' XPCOM pieces can be written in C++ or python and can even be prototyped in javascript.

fool for python
Wednesday, July 16, 2003

"Most of the time Javascript is only demanded for form verification or DHTML menus or rollovers."

Sorry, but that's just not true. There are some cases where you choice is Javascript or round-trip. Users are very unhappy with seemingly pointless round-trips. We are, after all, talking about making UIs that are comparable to desktop UIs, not making a generic web site.

Brad Wilson (
Wednesday, July 16, 2003

*  Recent Topics

*  Fog Creek Home