views:

137

answers:

8

I always seem to have this internal struggle when it comes to user interface. I build up an application "engine" and tend to defer user interface to after I get my algorithms working. Then I go back and forth trying to decide how to let a user interact with my program. Personally, I'm a fan of the command line, but I can't expect that of my users generally.

I really like what's possible in the browser in the age of web 2.0 and ajax. On the other hand it's not so hard to make a Swing front-end either, and you can generally count on a more consistent presentation to the user (though using a good javascript framework like YUI or jQuery goes a long way toward normalizing browsers).

Clearly both approaches have their merits and drawbacks. So, what criteria / parameters / situations should lead me to use a lightweight (e.g. web-based) GUI? What criteria / parameters / situations should lead me to use a heavier (e.g. Swing-based) GUI?

It is not my intent to start a flame war, merely interested in the community's constructive/objective opinions.

Edit #1 In light of the first few responses, I would like to clarify that I would like to deploy my application regardless, not host it on some internet server necessarily. So I would have to deploy with a light-weight web-server infrastructure a la Jetty/Tomcat or similar.

+1  A: 

One small factor you may want to consider is that the user will have go through some type of installation (albeit minimal) if you distribute a swing application.

Also a web application will allow you to accurately track the usage of your application (via google analytics or something similar). Not sure if that's a concern but it may be useful to you in the future.

toddk
+1  A: 

If it is a client-server application I would normally go for a web frontend for the application.

You will save yourself of countless problems with things like installed JRE versions, distributing upgrades, application permissions, disappeared shortcuts...

Iker Jimenez
A: 

If you anticipate there being frequent updates to the app then web based may be better since the user would not have to update the client or install a new client containing the updates. If you think that the user may need the ability to use the app while not conencted to the internet then swing would be better.

Just two things off the top of my head.

ChadNC
+1  A: 

You need to break the requirements of the application down to decide this...

  1. Do the users have Java of sufficient version installed? It will need to be, to run a Swing GUI.
  2. Do you have a web server?
  3. Do you need the flexibility of a Swing GUI or the accessibility of the web interface?
  4. Is Java Webstart and option, if so, you can distribute a Swing GUI via the web.
  5. Does your application perform extensive calculations or processing? If so, a client app may be the answer.

There are a million questions such as these. I would suggest a brain storming session and keeping track of all the pros and cons of each, adding a point score, than throwing it all away and going with your gut feeling :)

Chris Kannon
A: 

Think about the users and use cases of your project.

Do users expect to have access to it when they're disconnected from the Internet (for example, on an airplane or in a coffee shop with no Internet access)? Use Swing.

Do you want users to be able to access the same tool from different computers (for example, both at work and at home)? Use a web UI.

Also consider whether the user needs to save and load data, and whether the tool produces data files that some might consider sensitive (if so, storage on the web might be an issue).

David
A: 

Do make a quick guess I often try to ask myself/customers if the application has a high "write" demand. For a mostly read-only application a thin-client solution is perfectly well suited. But if a lot write actions are needed then a swing desktop application has more flexibility.

Personally I always prever a swing desktop application. It can easily deployed using Java Webstart.

Waverick
+2  A: 

It depends on the application and this is essentially a usability driven question (though there are considerations like data storage and platform requirements). Think of the pros and cons.

Pros of a lightweight Web UI:

  • Ease of distribution
  • Platform independent
  • Ease of maintenance

Cons of a lightweight Web UI:

  • Less environmental control
  • Markup standards vary between browsers
  • Requires a web server and everything that goes with it

Pros of an executable UI

  • More environmental control (i.e.: full screen applications, etc)
  • Not necessarily subject to latency and outages

Cons of an executable UI

  • Pushing updates may be more difficult
  • Requires installation
  • Potential platform requirements (frameworks, packages, etc)
  • Potentially requires knowledge of advanced networking topics (web services, etc)
hypoxide
Pros of a lightweight Web UI: Server side data storage and validation. This is arbitrary. For you maybe it's a pro, because you get a load of data to analyze your users. For users, it might be a con if that data is personal.
zedoo
Good point zedoo. That's hard to put in either category as a pro or con, but it's definitely a consideration.
hypoxide
A: 

Not knowing anything about your application I can not give the best recommendation possible. However I can state from personal/professional experience that installing an application on clients machines is a LOT more of a pain in the ass than it seems.

With AJAX/web you really only have to worry about supporting like three browsers. Installation messes/updates are only felt once when you deploy the product to the web server.

With like a stand-along Swing app, you get to deal with the really really big mess that is installing the application onto unknown systems. This mess was so bad that things like AJAX were really pushed along to make web apps behave/feel like a real native app.

tmeisenh