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."
Java, XUL (Score:1)
Another possible option is XUL, Mozilla's user interface language. While it is an XML dialect and fairly simple to use, I wouldn't call completely stable yet, and it forces you to deploy Mozilla/Netscape to all desktops.
I personally prefer web interfaces (especially from an administration/support view) since you no longer have to deploy client applications - a real bitch! Any changes to the application are right there for all users. Unfortunately, HTML doesn't allow for particularly rich user interfaces.
If it is absolutely imperative that there are certain UI aspects be implemented that cannot be done with HTML, you may be forced to write a client application. However, if you can convince everyone involved to keep their expectations within bounds, I would suggest a web interface.
Future proof (Score:1)
This protocol could be as simple as some XML/HTTP or whatever you like. You can then implement one server and whichever clients you like.
Once you have done this, you can develop a web client (which just translates web forms to and from your protocol) or a native UI.
If you DON'T do this and you go the web route, your web app will be a combination of the server+client components and it will be difficult to seperate them in the future.
Speaking from experience here...web interface not bad, but the fact it is co-located with the server encourages short-cuts best not taken.
desktop.com (Score:1)
Right now we are attempting to keep from having to write yet another VB app and migrate to the web based apps.
Does anyone know what happened to the desktop.com stuff and if there is anything like it (in the way of dev tools). Note: the desktop.com stuff was totally DHTML and scripting, no java on the client.
Re:One thing to consider (Score:1)
i think that a web server could be more secure, since the amount of damage you could do with a users account would probably be less, if it was run off a fileserver, everybody would need direct access to the files, but a web interface could limit the things you could do.
in either case, if the server with all the data is compromised, you're screwed
Re:One thing to consider (Score:1)
Im assuming this solution will be used from a centralized location or office, rather than from locations distributed in different areas/cities/etc. It more than likely would not be more difficult to develop a dekstop version (if they have good engineers) than the web version, so I'm not sure I can see a real advantage to a web interface, other than possibly write once, run anywhere ability. That could be good or bad tho, depending on their needs and paranoia.
I say write a desktop version and run it from a file server, or install it where it is needed.
Keep it open (Score:1)
We have all of the business logic in scripts on the server. These scripts take http requests and respond to them with XML. We then made a bunch of client pages (web), which completely duplicated the current functionality, but containing only presentation logic. Now, the system is open enough that we can support multiple clients. Our customers can even write their own. They can be web, desktop app, palmos, java, anything that can open an http connection, and we can concurrently support any number of different versions.
So, my suggestion, would be to pick whichever one is easiest for you, but keep the interface seperate, so you can create another client later, and not have to touch the business logic. We haven't rolled out the new version of it (so this isn't tested advice), but we have very high hopes for the maintainability and flexibility of this structure.
cross platform libraries (Score:1)
I doubt that you need to access the graphics framebuffer or the audio device directly since you are actually considering using a web interface, but if you do need to create your own graphics, you can take a look at www.libsdl.org. A good example of a program using libsdl is at www.winbolo.org.
Re:Java? (Score:1)
Anyways, Java is a good option for both. You could write the middle and back end to be nutreal, and a servelet to dish out the webapp, and an applet to dish out the application. Works great for me anyways.
Re:Java? (Score:1)
If you're going to go the Java route Java Web Start [sun.com], would probably be better than an applet.
(not that I've actually used it, mind you, but I do like the fact that it appears to be free of the browser-related issues that can occur with applets)
Of course, then you'll need to roll out JWS itself to all your computers...
---
Re:One thing to consider (Score:1)
-- Eat your greens or I'll hit you!
Java? (Score:2)
One thing to consider (Score:2)
My experience (Score:3)
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? (Score:3)
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 (Score:3)
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 (Score:3)
Pros of web-based client:
Advantages of a roll-your-own client: