Web-Clients vs. Desktop Clients?

lundmatt asks: "My company is a software development institution that has been around for awhile. We are in the process of designing a large in-house tool to merge our current bug tracking, version control, design and implementation processes, and a few other stand-alone systems. A large debate we're having is whether to implement a Web-based client or a desktop application client. Most people fit neatly in a pro-Web camp and others in a pro-desktop application camp, unfortunately we are in a position where we can't develop both." There really is no right answer to this question, as many applications can adopt themselves into either environment. Sure, there are several applications that can benefit from one or the other, but the concepts of Web and desktop are dovetailing, and have been for years.

"The argument of the desktop proponents is that Web interfaces are not productive for a tool which would benefit from a lot of rich GUI controls such as trees, etc. The Web-proponents argue that Web clients are no less productive. The Web-proponents argue that deployment effort is zero though the desktop proponents feel this is a negligible issue for us. Surely we are not the first company to debate this though I've had a difficult time finding 'unbiased' studies that compare and contrast the two options. I hoped that some of your readers would have some opinions about this and since we're all SlashDot fans, we thought we'd drop you a line."

Comments

Java?

[_w00d_]

Being brand new to Java programming and not knowing the specifics of your project, I definitely wouldn't be the best authority on this. But the question I have is this: couldn't you write the application in Java and use it both as an applet and a standalone application? It seems to me that this would appease both parties in this case as well as eliminate a lot of porting efforts if you ever decide to roll out your application to other platforms.

One thing to consider

[TotallyUseless]

If you go with a web based interface, you might have to worry about what could happen if a script kiddie gets access to the programs/data/etc. If you used a desktop based approach, it would prolly be easier to keep secure. I have been dealing with a similar problem where I work (although on a smaller scale) and I spent many nights debating which way I should do it. I ended up using a mixture of both, but that appears not to be an option for you.

My experience

[Stormie]

The last place I worked, we were pondering the same question. In our case, we were starting a project to rewrite some old systems (which ran under VMS, with a character mode interface via telnet), with something more modern, namely VB + MS SQL (hey, the company was in bed with Microsoft, there was no way management was going to pick anything else).

Now, I can't tell you which is better because I left the company and the country before a decision was made. :-) But I can tell you what we were thinking. Note that this was from the perspective of a totally Microsoft shop. Depending on your situation, certain factors (like: a web front-end should be inherently cross-platform) which meant nothing to us, might mean something to you.

Distribution: This was a big one for us. We had a strong culture of fixing bugs and adding features by quickly editing and recompiling some code.. on the live system.. (yeah, we had a dev system as well, but for quick changes, we took the "cowboy" attitude and just did it in live). So, it was important for us not to lose the ability to do an instant fix. This pointed us in a web direction.

Ease of Development: I guess from your description of having two "camps" that you have people on hand with the necessary skills to go either way. We didn't - we knew VB, but we were learning as we went when it came to web work. Remember that "what you can do" is often a far more important issue than "what you should do" when it comes to corporate IT.

Quality: As your desktop advocates suggest, you can just plain do a better interface with a local exe than with a web frontend. If you go the web way, you just know that some manager will want some feature which is really, really hard to do nicely on a web page - but you can always do there things in code.

Other things: Using a web server is one extra point of failure. But its also one extra layer of scalability (if it turns out your "business logic" is a bottleneck). But of course you could do a three-tier design without the middle tier being a webserver. If your in-house tool ever needs to be accessed from "out of the house", it's surely easier if all someone needs is a web browser. A client-server application should require less network bandwith than web traffic. Also don't forget that you could do a web page which was basically just a "carrier" for a bunch of Java applets or ActiveX controls, to get the distribution advantage of the web interface with most of the other advantages of the desktop app.

Oh well, just a few ideas for you to throw into the pot..

Is web portable?

[bluGill]

Web based clients are not nessicarly easier to devolp, nor are they nessicarly portable. Here at work I'm forced to use a web based system that only works with IE on windows. IE on solaris or netscape on anything doesn't work right. (Ironicly most of the devolpers use solaris on their workstation) Because of java (bad use of java) we have a slow, bloated, non-portable interface that is hard to use. We could have made a windows verison that was better in all aspects, but the idea of cross platform was too important when we started, Java (not yet at 1.0) was the best thing. We took it, ran too soon, and nobody is willing to admit we need to start over from scratch despite the complaints.

Web based clients are good for somethings, and poor for others. Java is cross platform in theory, but combins netscape's bad implimentation with Microsoft subversion and it is useless. Straight executables are good for speed, but remember that your algorythms and data structures still determin speed. Executables are great if everyone uses windows (or unix/mac, but that is rare) every day, but annoying to those who don't normally use windows, but have to just for the one application.

So really the question is: Do you have users who do not normally use windows who would have to now. If so is there a problem giving them a windows machine? If everyone uses windows, the advantages of an application outweigh everything else. If you have to support a number of different operating systems, then web based wins, make sure they stay cross-platform and nothing is done to compromise speed.

PLEASE have only one and stick with it

[dmorin]

We just went through this with a large content repository software vendor. We'd been using the desktop client on their recommendation because their web client always sucked. Well, with the new version of the software, they fundamentally revamped both -- but internally,they kept a desktop development team and a web development team. So now depending on who you talk to they recommend one or the other solution, and neither is 100% -- they have some major overlap, but they come off looking like a Venn diagram where each tool can do certain things the other can't.

We wanted a web client. We have dozens of users spread across Boston and Chicago, both on the company net and wanting access from home. It's difficult to administer that sort of installation (especially once the software patches start coming out). The vendor wants us to use the web client, because most of the new features of the new version are in that client. Our existing customer wants us to keep using the desktop client because they already know that one and don't want to rock the boat.

The problem is that the web client stinks. LOTS of things wrong with it, not bug wise, but just bad-interface wise. So several times I day I utter the following sentence: "Wow, the web client is lousy at X. Does that mean we have to use the desktop client? But shoot, we can't, because the desktop client is lousy at Y." We're hoping to force the vendor to accept our list of changes and modify the web client, it's our only hope.

Did that answer your question? A web client, please. And DONT make it IE/5.5 only, we hate that. And please make sure that it's full featured, don't rush it out the door just because you want a web interface and then realize that there are fundamental features you forgot to support.

Depends, but web probably works out better

[raju1kabir]

Pros of web-based client:

• More secure. Communications travel through well-understood mechanisms (HTTP GET/POST) for which there are oodles of data-sanitizing code samples available. Protocol handlers themselves (browser and HTTP server) are under intense scrutiny, and chances are someone else will find a problem, leading to a public update, before someone on your site does.
• Faster to develop. The main advantage of using a web browser as a client is that someone else has already written all the GUI and event-handling code, and abstracted it to a high level (HTML). This is typically the most annoying and painstaking part of software development, so consider yourself lucky.
• Cross-platform. If you use a web interface, you are not shoving your choice of platform down anyone's throat. Your staff can use what they're comfortable with.
• No need to play OS upgrade catch-up. When your users start using a new version of their favorite OS, you don't have to worry that it will break your client software.
• Easier to find developers/maintainers. Competent web programmers are easier to find than competent application developers.
• Familiar interface. Users already know how to interact with web-based applications.

Advantages of a roll-your-own client:

• More flexible, powerful GUI. Because HTML forms are so generalized, there are some things they don't do well - oddball user interface elements, highly interactive elements, etc.
• Speed. If you optimize your client for the specific purpose, you don't have the overhead created by all the unused functionality in a general-purpose browser, protocol, and server.