Custom Client or Accept Browser Limits

Hello All,

I am looking for your thoughts on building custom web clients. (Desktop Apps that use http to communicate with server via a custom messaging system) vs. Standard Browser Based Web app.  I need to 'Webify' and existing Custom Desktop/Lan Document Management/Workflow application and need to decide between Std. Browser, Custom Client, Flash etc. for the front end.  Have any of you ever built a custom client, any thoughts on this would be greatly appreciated.

ppjm99
Monday, January 12, 2004

If you have been building software using ide's like Delphi and Visual Basic, and really know less rather than more about web application development, than a custom browser or Flash would be appropriate if you haven't made the investment to check out Microsoft Web Forms.net.

If you are more familiar with web design, then the answer simple, regular browser or custom browser (web browser control in an app).

Li-fan Chen
Monday, January 12, 2004

I'm surprised you're even allowed to decide. At the jobs I've had the decision was always to use a browser simply 'because'-- even if a rich client would have served them better.

It's getting to seem that there's nothing you can't do in a browser. I've seen some really rich functionality -- including capturing keystrokes.

If you choose a browser then make sure you support only one brand.

Steve
Monday, January 12, 2004

IT usually prefer browser based applications as they are so much easier to deploy, and it's quite easy to create links to browser based apps from an intranet.

Matthew Lock
Monday, January 12, 2004

I have been building software for a long time and although my experience with Web apps is not as much as others, I have no worries over being able to implement the best technology for the Job.  An example of one of my concerns would be that we use an explorer style treeview interface for part of our app, although I think these can be implemented either as java applets or using some kind of server side code that uses graphics and tables to emulate a treeview couldn't I just keep my app the way it is and just use the internet as an html data pipe for files and messages instead of the client server/lan arrangement we currently have.  My early experiments with .Net performance a while ago where not that encouraging, perhaps it has improved.

ppjm99
Monday, January 12, 2004

The difference is not very much if you stick with IE, including code base issues. An embedded ActiveX Control is as good as as free standing client. The aforementioned Key Stroke capture being the case in point

Indian Developer in India
Monday, January 12, 2004

Anyone who thinks that the real advantage of Web Apps is deloyment you may want to look into .NET Web Deploys for Windows executables and the J2EE equivalent Java Web Start.

I really think the trend in the industry is going to move back over to the rich client - as deployment gets easier and easier.

Looks like future features of Windows & .NET are moving to smart clients & web services.

GenX'er
Monday, January 12, 2004

For a rich UI, running in the browser can be very contraining, even with an ActiveX control.  Sometimes you just need control over the main message loop.  OTOH, most people are very comfortable working within a browser-based application, because they can use it with almost no instruction (as little as "go to www.xxx.yyy/app").  I like WebEx's strategy- they have a really nice webconferencing app that you launch from the browser, but ultimately runs in it's on process.  And everything is installed and updated on demand.  Users keep the warm fuzzy launch-from-a-URL feeling.

Ken
Monday, January 12, 2004

"IT usually prefer browser based applications as they are so much easier"

Easier for IT, not for the user. As IT resources become commoditized, perhaps ease for the user will take more precedence.

m
Monday, January 12, 2004

"""As IT resources become commoditized, perhaps ease for the user will take more precedence."""

You've got to be kidding.

Phillip J. Eby
Monday, January 12, 2004

Users have lowered expectations of web applications.  They accept the latency, as long as it doesn't get too bad.

On a native client, the users will bitch to no-end if the "Sort" button doesn't redraw fast enough.

Supporting a web-app is much easier (if you can impose some limits on browsers), as you only have to deploy updates to one place.

On the other hand...

Web apps discourage innovating new UI controls.

If you update the app, all the users are immediately upgraded.  A lot of users in important positions are technophobes who get utterly confused if you so much as change the color scheme.  Upgrading the web app will throw them into conniptions and force them to be completely retrained.  With a native app, you could just choose not to upgrade them if they don't need the new functionality.

Richard P
Monday, January 12, 2004

we recently decided against a browser based solution because of the latency.

twas data entry intensive and the delay whle pages were saved/loaded was going to have a significant impact on the over productivity.

FullNameRequired
Monday, January 12, 2004

  Recent Topics

  Fog Creek Home