66366 members! Sign up to stay informed.

Sponsored Links


Resources

.NET Research Library
Get .NET related white papers, case studies and webcasts

News News News Messages: 62 Messages: 62 Messages: 62 Printer friendly Printer friendly Printer friendly Post reply Post reply Post reply XML XML XML

Debate: Rich Clients or Browser Interface?

Posted by: Chris Anderson on September 21, 2004 DIGG
Thick clients vs. Thin Clients... Rich vs. Reach... Now "Smart" vs. Dumb?

Smart clients, or whatever you want to call them, are about delivering rich immersive experiences to users. Whether you implement your smart client using Flash, DHTML, Windows Forms, or Avalon - the difference between a smart client and "the other thing" is the experience.

I would argue that Outlook Web Access is probably the smartest DHTML based application I have ever seen. It delivers a pretty compelling user experience, with a great (i.e. none!) installation experience. OWA (as we commonly call Outlook Web Access) pails in comparison to the full Outlook client in usage experience. Rich drag drop, intellisense, autocompletion, smart tags, and more! In addition Outlook allows for extension by other developers - look at applications like Lookout and Newsgator. Outlook is so immersive, that there are many people that work their entire day in no other application than it.

Arguably there are exactly 3 reasons why people wouldn't build smart clients; Cost, Availability, Deployment.

Cost - "Smart clients are more expensive to produce". When looking at a modern development platform, like WinForms, it is hard to make this argument. Great GUI designers and rich control sets generally make it simpler and faster for developers to author smart clients. There is no server post back or session state to deal with. I will give you that creating a great user experience can be expensive - involving a graphic designer, user experience engineer, and usability studies - but I would argue that is true of any great experience. Ask the folks at Disney if it would be cheaper to build the themepark without having to make everything look perfect?

Availability - "Smart clients require you to deploy their runtime", also known as "Smart clients lock you into a platform". Flash, DHTML, Windows Forms, and Avalon - all require the deployment of some form of runtime. Some smart clients require bigger runtimes - Win32 requiring an entire OS. Generally, the runtime dictates the functionality available to the platform. Ubiquity of the runtime removes this barrier to installation. The .NET framework is installed on 10s of millions of computers. Internet Explorer is installed on 100s of millions of computers. This is a real concern for smart client development.

Deployment - "Smart clients require nasty installation programs", or "Smart clients break my machine". Both are variations on a theme - smart clients need to support zero installation, just like their web counterparts. With .NET 1.x based applications you have a great installation story, with .NET 2.0 you get ClickOnce which really delivers an completely seamless installation. With Avalon you will get a great story for browser integration and no-install applications.

When all is said, really availability is the only major detractor (cost is tunable based upon the experience you want to offer, and deployment is improving so rapidly as to be a relatively small barrier).

Applications authors must differentiate themselves, as do producers of any product. Developers that choose to offer a more compelling experience will be the ones to win. Smart clients are the way to produce rich immersive experience.

Threaded replies

·  Debate: Rich Clients or Browser Interface? by Chris Anderson on Tue Sep 21 16:20:06 EDT 2004
  ·  Chris Sells on Smart Clients by Chris Sells on Wed Sep 22 15:46:00 EDT 2004
    ·  Browser-Based clients are "Good Enough" for Mom by Mike Parsons on Wed Sep 22 16:47:29 EDT 2004
      ·  Browser-Based clients are "Good Enough" for Mom by Tom Jones on Wed Sep 22 17:06:04 EDT 2004
      ·  Not "good enough" for my wife by Chris Anderson on Wed Sep 22 20:31:31 EDT 2004
    ·  Back to FAT client? by Simon Littlehales on Wed Sep 22 17:15:14 EDT 2004
      ·  Back to FAT client? No. Forward to Smart Client by Paul Ballard on Wed Sep 22 18:22:02 EDT 2004
        ·  RE: Back to FAT client? No. Forward to Smart Client by Chris Sells on Wed Sep 22 18:32:46 EDT 2004
          ·  RE: Back to FAT client? No. Forward to Smart Client by Mehul Patel on Wed Sep 22 20:13:19 EDT 2004
          ·  RE: Back to FAT client? No. Forward to Smart Client by Philip Stockwell on Thu Sep 23 06:13:26 EDT 2004
          ·  It works for Messenger, yes by Bertrand Le Roy on Thu Sep 23 18:59:53 EDT 2004
        ·  Back to FAT client? No. Forward to Smart Client by Simon Littlehales on Thu Sep 23 12:38:58 EDT 2004
          ·  Back to FAT client? No. Forward to Smart Client by Paul Ballard on Thu Sep 23 13:04:08 EDT 2004
            ·  Back to FAT client? No. Forward to Smart Client by Simon Littlehales on Thu Sep 23 15:48:58 EDT 2004
    ·  Disconnected mode, GUI responsiveness/scalability are the keys by Jim Sally on Thu Sep 23 14:44:33 EDT 2004
    ·  The big picture by Rajesh Hari Parsad on Thu Oct 07 16:24:28 EDT 2004
    ·  I just wanna say - I was right by Simon Littlehales on Mon Apr 26 19:12:31 EDT 2010
  ·  Another strong point of thin client is ubiquity of the data by Bertrand Le Roy on Wed Sep 22 18:03:05 EDT 2004
  ·  Ehy CHOOSE ? by Rod Pineda on Wed Sep 22 20:33:07 EDT 2004
  ·  Why CHOOSE ? by Rod Pineda on Wed Sep 22 21:02:35 EDT 2004
    ·  RE: Why CHOOSE ? by Chris Sells on Wed Sep 22 22:09:40 EDT 2004
      ·  RE: Why CHOOSE ? by Paul Ballard on Wed Sep 22 23:17:15 EDT 2004
        ·  RE: Why CHOOSE ? by rory Winston on Fri Sep 24 07:52:52 EDT 2004
          ·  RE: Why CHOOSE ? by Paul Ballard on Fri Sep 24 10:30:00 EDT 2004
            ·  RE: Why CHOOSE ? by Mehul Patel on Fri Sep 24 11:38:57 EDT 2004
          ·  мишка, привет by julia prokulevich on Thu Feb 03 11:29:49 EST 2005
  ·  Definitions by Harris Reynolds on Wed Sep 22 23:19:06 EDT 2004
  ·  Network is the key by Fran?ois Lemaire on Thu Sep 23 04:38:15 EDT 2004
    ·  Network is the key by Harris Reynolds on Thu Sep 23 10:35:03 EDT 2004
      ·  Now that's compicated! by Fran?ois Lemaire on Thu Sep 23 12:29:25 EDT 2004
        ·  RE: Now that's compicated! by Chris Sells on Thu Sep 23 13:36:43 EDT 2004
          ·  That's your argument? by Shannon Hager on Mon Sep 27 23:13:10 EDT 2004
            ·  That's your argument? by Natty Gur on Tue Sep 28 11:40:14 EDT 2004
              ·  That's your argument? by Mike Parsons on Tue Sep 28 12:27:55 EDT 2004
                ·  That's your argument? by Natty Gur on Tue Sep 28 13:20:22 EDT 2004
                  ·  re: That's your argument? by Chris Sells on Wed Sep 29 10:46:37 EDT 2004
                ·  That's your argument? by Chris Sells on Wed Sep 29 10:43:37 EDT 2004
            ·  That's your argument? by Chris Sells on Wed Sep 29 10:41:46 EDT 2004
  ·  Innovation by Mike Parsons on Thu Sep 23 08:07:19 EDT 2004
    ·  RE: Innovation by Chris Sells on Thu Sep 23 11:24:44 EDT 2004
      ·  Progress and Innovation by Michael Plavnik on Fri Sep 24 00:10:38 EDT 2004
        ·  АУ! by julia prokulevich on Thu Feb 03 12:03:11 EST 2005
  ·  What about business needs as a factor? by Natty Gur on Thu Sep 23 16:28:22 EDT 2004
    ·  RE: What about business needs as a factor? by Chris Sells on Thu Sep 23 18:51:09 EDT 2004
      ·  RE: What about business needs as a factor? by Natty Gur on Fri Sep 24 12:34:48 EDT 2004
        ·  RE: What about business needs as a factor? by Chris Sells on Fri Sep 24 14:13:23 EDT 2004
          ·  RE: What about business needs as a factor? by Natty Gur on Fri Sep 24 16:58:54 EDT 2004
          ·  I can't rely on a single client platform by Fran?ois Lemaire on Sat Sep 25 05:06:37 EDT 2004
  ·  Browser Renaissance by Mike Parsons on Fri Sep 24 08:35:48 EDT 2004
  ·  Debate: Rich Clients or Browser Interface? by Lloyd Benson on Sat Sep 25 08:29:39 EDT 2004
  ·  Recent Survey by Mike Parsons on Tue Sep 28 09:13:23 EDT 2004
    ·  re: Recent Survey by Chris Sells on Wed Sep 29 11:14:05 EDT 2004
      ·  re: Recent Survey by Mike Parsons on Wed Sep 29 15:54:15 EDT 2004
        ·  re: Recent Survey by Scott Lorenz on Tue Oct 05 14:45:00 EDT 2004
          ·  re: Recent Survey by Chris Sells on Wed Oct 06 00:09:39 EDT 2004
            ·  re: Recent Survey by Scott Lorenz on Thu Oct 07 11:13:35 EDT 2004
        ·  re: Recent Survey by Mark Wilson-Thomas on Wed Oct 06 04:33:47 EDT 2004
  ·  Bosworth's Opinion by Mike Parsons on Wed Sep 29 18:44:52 EDT 2004
  ·  Smart browsers rather than smart clients by Gerke Geurts on Wed Sep 29 19:41:17 EDT 2004
    ·  Smart browsers rather than smart clients by Mike Sabot on Tue Oct 05 14:34:50 EDT 2004
    ·  Smart browsers rather than smart clients by Mark Wilson-Thomas on Tue Oct 05 14:56:41 EDT 2004
  ·  Smart client technology definitely has its own niche by jean hibbert on Wed Oct 06 13:23:20 EDT 2004
  ·  Fundumental Similarity by Andrew Miadowicz on Thu Oct 07 14:53:43 EDT 2004
  Message #139169 Post reply Post reply Post reply Go to top Go to top Go to top

Chris Sells on Smart Clients

Posted by: Chris Sells on September 22, 2004 in response to Message #138933
As amazing as Outlook Web Access is, would you rather use it or the real Outlook client? I've asked this question of conference talk crowds again and again and the overwhelming majority always votes for the real Outlook client. The reason is simple: no matter how far you push the browser, it just doesn't offer users the richness, responsiveness or flexibility that the Windows platform as a whole provides. For developers, anything at all interesting isn't nearly as easy to implement on the web as we'd like, whether it's state management, rich UI in a cross-browser and cross-platform way or what to do when the Back button is pressed in the middle of a crucial operation. Of course, things like disconnected operations and cross-application integration just plain don't work with web applications.

That's not to say that web applications don't have their advantages. If the lowest common denominator UI can be made to work for your application, you get seamless distribution and seamless updates as well as a cross-platform UI. If your first consideration is targeting platforms other than Windows for your client-side applications, than web applications are absolutely the way to go.

However, if you can target Windows, than "Smart Clients" are where you should be focusing your efforts. The goal of Smart Client technologies is to work in the real-world semi-connectedness that computers find themselves in, moving between wired and wireless nodes as well as connectivity dry zones, like the car or the airplane. Smart Clients mix the best of both Windows and web applications, including rich UI, cross-application integration, disconnected operation and developer flexibility, with the deployment and updating capabilities of web applications. Microsoft's latest efforts in Windows Forms 2.0, Avalon, Visual Studio 2005, Visual Studio Tools for Office, Compact Framework, ClickOnce, and WinFX are all about building Smart Client applications that take advantage of the platform as well as connectivity when it's available.

Since .NET 1.0 and No-Touch Deployment, Smart Clients are what I've dedicated my Windows developer life to. If you are targeting the Windows platform, why wouldn't you take advantage of these technologies? Why would you lock yourself into what the browser provides when you can have everything that Windows provides?

  Message #139184 Post reply Post reply Post reply Go to top Go to top Go to top

Browser-Based clients are "Good Enough" for Mom

Posted by: Mike Parsons on September 22, 2004 in response to Message #139169
Interesting thread ... one question though Chris ... how many of those conferences included "real users", not developer types? I think the trap we fall into as software engineers (and Alan Cooper would certainly have something to say about this) is that we design/develop things for ourselves, not for real end-users. I love the Outlook rich client but you know what, OWA, Hotmail or Gmail is "good enough" for my Mom.

I think that we, as an industry, are starting to move back to more complex "Rich/Smart Clients" because that's how we think ... we love complexity. The browser-based stuff was totally new and required us to "dumb down" our thinking ... something that most software engineers loath to do. I agree that you can't do everything in a browser-based client that you can do in a Smart Client but for the average use-case scenario, you really don't need to.

I think one of the main problem we ran into during the era of building browser-based apps is that we tried to do everything we previously did in client/server based applications. We tried to mimic the controls, widgets, navigational paradigms, etc of rich clients. What we should have been doing instead is "rethinking" these things, coming up with new and simpler ways of doing User Interfaces/Experiences.

Don't get me wrong, I think there is still a place for Rich/Smart Clients, although I think we are moving backwards in terms of providing users with simpler more user friendly software. I got this feeling the other day watching a Channel9 video of how easy it was to create an Outlook/IE/Messenger clone in Whidbey ... this is progress?.

  Message #139193 Post reply Post reply Post reply Go to top Go to top Go to top

Browser-Based clients are "Good Enough" for Mom

Posted by: Tom Jones on September 22, 2004 in response to Message #139184
I disagree. I have come across many a user who can tell the difference between the usability of a windows based app as compared to a browser based app. Users understand responsiveness they know how long something takes to run. Your mom will know the difference between a windows app and a browser app if she uses either for an extender period of time. Granted a first time user wouldn’t know the difference between the two, but we as developers do.

TJ

  Message #139195 Post reply Post reply Post reply Go to top Go to top Go to top

Back to FAT client?

Posted by: Simon Littlehales on September 22, 2004 in response to Message #139169
Hmmmm. Must admit all this "FAT" client stuff worries me slightly. I can see the lure of a return to this technology - especially from a developer's point of view but...
Our company made the decision to move to thin (cheap?) clients and move everything over to a browser where possible. This means we can run all our apps on very creaky old PC's (or even Wyse terminals) with almost instantaneous response from the web server. This has saved us a fortune in hardware upgrades.
When ASP.NET came along it was G-R-E-A-T - the intranet just grew & grew and support & administration has fallen to almost zero! Everybody knows how to work a browser so even the amount of training has fallen. On top of this, we have all the web standards which are finally taking form (DOM, CSS, XHTML, XML, ECMAScript). Better and better! I can see Nirvana just around the corner! Also, I love the absolute purity of developing for one Interface for both our internal AND external systems. One knowlege set - any platform, any place! Wow! we've really made the right decision, i thought!
Then along comes OneClick - brilliant technology, tempting, easy, responsive, beautiful, slick UI's etc etc.
Something at the back of my mind however is saying - "Oh O! Here we go again...!". We're gonna have to develop everything twice for both platforms. Just as I was getting to the top of the learning curve, ready to jump on my sledge & ride - I see I'll now have to learn all that FAT client business AS WELL as the web stuff! The slope's just got steeper! Also, those creaky PC's will begin to look creaky again etc etc!
OK - I could just continue to develop in ASP.NET, but I have a nasty feeling that all the giant improvements in the browser-based world that have happened in the last 3 years will now slow down as the World moves back to the FAT client paradigm! And just as we were finally getting there!
Hope I'm proved wrong! The trouble is, I can also see myself being tempted by the great sense of relief we'd all get by returning to that nice FAT world!!!

  Message #139200 Post reply Post reply Post reply Go to top Go to top Go to top

Another strong point of thin client is ubiquity of the data

Posted by: Bertrand Le Roy on September 22, 2004 in response to Message #138933
You're forgetting one of the best reasons why you would use a web mail client instead of Outlook: you can consult your mail from any computer.
Of course, if your mail server is not a plain SMTP/POP server, like Exchange, for example, you can get the same ubiquity with the rich client, but most people have their mail on a standard SMTP/POP server, or on a web mail.
The same is true of many applications: the thin client also has the data in one single place. No data synchronization necessary, which is a big selling point both for developers and end-users.

  Message #139202 Post reply Post reply Post reply Go to top Go to top Go to top

Back to FAT client? No. Forward to Smart Client

Posted by: Paul Ballard on September 22, 2004 in response to Message #139195
I have a nasty feeling that all the giant improvements in the browser-based world that have happened in the last 3 years will now slow down as the World moves back to the FAT client paradigm!
Huh? Perhaps I've missed something but the last version of HTML to be released by the W3C was in 1997. Okay, so it's now 2004 that means 2004 minus 1997, carry the 1 and that makes.... 7 years ago! For those of you keeping track, here are some of the other great releases from 1997.

Intel releases the Pentium II 233Mhz Processor!
Windows introduces Windows 98!
IEEE introduces the 802.11 wireless standard!

The point is, browsers are based on a feature set that is by computer terms, antiquated. In spite of new browser releases and new add-ons, the underlying technology has not kept pace with modern technology. Now if you look at Windows as also being a platform for delivering applications, it has seen advances since the Windows 98 days (Thank Heaven or Redmond, whoever was ultimately responsible). It only makes sense to me to want to leverage those advances for the benefit of our users.

Come on, give in to temptation! :-)

  Message #139205 Post reply Post reply Post reply Go to top Go to top Go to top

RE: Back to FAT client? No. Forward to Smart Client

Posted by: Chris Sells on September 22, 2004 in response to Message #139202
There's absolutely no correlation between where the data is kept and whether the client takes advantage of the platform or not. Windows Messenger is proof of that, i.e. all of my buddies are kept on the server, but the client is a smart one. Just because current fat clients don't offer the option to keep data centrally just means that they're not smart.

  Message #139218 Post reply Post reply Post reply Go to top Go to top Go to top

RE: Back to FAT client? No. Forward to Smart Client

Posted by: Mehul Patel on September 22, 2004 in response to Message #139205
If we ask ourselves, back in time, HTML , web browsers were developed to deliver static data. Then things improved, we became dynamic, there came javascript, HTML DOM, and thats about it.

No major computing happens today as far as Browser goes, may be computing CSS. But one major advantage is if you are using Linux, or Mac or Windows you can see documents, or interact, that much can be assured. Depending on Browser you use , you get good view or distorted view.

Now if smart client technology delivers much in one area, what about other area, can i see smart client apps on Linux or Mac? That has to be resolved if smart clients want to surpass HTML/CSS/Javascript world. Otherwise we are running too far, before tieing our laces. XAML, XUL etc and Object Model , Scripting engines, need to work in open ways... If not HTML/CSS/Javascript are here for a long time. ASP.Net is here for a long time, and so as JSPs...keep coding 'em....getElementById("iAmStayingTill2030")

  Message #139222 Post reply Post reply Post reply Go to top Go to top Go to top

Not "good enough" for my wife

Posted by: Chris Anderson on September 22, 2004 in response to Message #139184
how many of those conferences included "real users", not developer types?
Good point, most conferences I attend are developer conferences.
I love the Outlook rich client but you know what, OWA, Hotmail or Gmail is "good enough" for my Mom.I think that we, as an industry, are starting to move back to more complex "Rich/Smart Clients" because that's how we think ... we love complexity.
I use my wife as a good example. At work (school teacher) she uses Outlook. At home she uses a combination of OWA and Hotmail. Basically she complains about Hotmail about every other time she uses it. There was a set of time where a good percentage of her mails would get "lost" because she hit the back button or accidentally clicked a link. She often hits "missing" features in OWA that she is used to in Outlook. Overall, as an average user, I would say she much prefers the rich clients to the browser apps.
The browser-based stuff was totally new and required us to "dumb down" our thinking ... something that most software engineers loath to do.
Forcing a "dumb down" by performing a frontal labotomy isn't the most productive solution. I look at applications like Messenger - simple, intuitive, easy to use. Yes, many products have massive feature bloat, but the right solution is to simplify, not remove the IQ.

  Message #139224 Post reply Post reply Post reply Go to top Go to top Go to top

Ehy CHOOSE ?

Posted by: Rod Pineda on September 22, 2004 in response to Message #138933
Both technologies has their own merits and environtments that are better suited for them.

Smart Lite Clients is the way to go,

  Message #139228 Post reply Post reply Post reply Go to top Go to top Go to top

Why CHOOSE ?

Posted by: Rod Pineda on September 22, 2004 in response to Message #138933
Thats right , there is no reason to choose either one over the other, both are amazing application development technologies that can be used, together or independent, depending of the requirements of the application. It is like that in all other areas of life, (eh. let me see , last time I checked all I owned were blue suits, it's great for meetings but I get stress out when playing b-ball and it sucks when I swim at the beach).

Let me tell you that i will take my yahoo account over outlook (fat, skinny or beatiful) any time and I just wish hard to find a lite implementation of AIM, that doen't require installing any software.

I also would take my FAT office word or visio over any browser based writing or diagraming tool. ( What real FAT applications we developers use ? Damm ) I want to see you writing .net apps on a browser based tool , ehhh.

Personally, I think this is a Big comapny ( MS, IBM, SUN ) marketing issue, see if I choose to develop on a FAT platform , those guys will sell more tools, Operating systems and will have an strategic advantage over their rivals. If I choose Lite , universal development , they screwed as They can not force me to choose their stuff.

So my recommendation is to support both as their a need for both

1. Strong standards-based solutions on lite , smart technologies that are well supported buy LOTS of vendors and run on MULTIPLE deployment browsers , such as DOM, CSS, XHTML, XML, ECMAScript. In fact, Support and Demand that these standards improve and grow over time.

2. Excilarating VENDOR specific, OPERATING SYSTEM specific technology like .NET , JAVA that offer HEAVY, LOCKING but FAST, BEATIFUL, TECHNICALLY AMAZING development tools. Applications will look better , behave better and have a better code foundation. ( ehh, also I will charge more , hehe, and more fun to develop)

The point is , let CUSTOMER requirements guide you on what technology platform you will use and why.

Your Pizza-Lover Deluxe
Rodrigo Pineda-Icaza

  Message #139235 Post reply Post reply Post reply Go to top Go to top Go to top

RE: Why CHOOSE ?

Posted by: Chris Sells on September 22, 2004 in response to Message #139228
I'm with you, Rodrigo. If you can target Windows, you should. If you need the reach of the browser, that's OK, too.

  Message #139239 Post reply Post reply Post reply Go to top Go to top Go to top

RE: Why CHOOSE ?

Posted by: Paul Ballard on September 22, 2004 in response to Message #139235
Before we agree to shake hands and part friends as one big happy Thick/Thin world, I'd like to know the community's thoughts about these topics.

  1. Browsing the Internet, or even the Intranet is a fundamentally unsafe thing to do. We all complain as one vulnerability after another is found in IE and FireFox, but should we really expect this to be safe. Consider what the browser is doing. We routinely, (you're doing it now) download scripts, executables, video streams, etc. from computers we know nothing about and then we execute them on OUR machines, in OUR networks. Of course this is going to be unsafe. So then if we are determined to execute code from people we don't know, why do we expect a browser, an application whose design if not actual source code dates back to the days before hackers wore "hats" to protect us?
    Rich Clients on the other hand are executed under Code Access Security. Now I'm not naive enough to say that this ensures complete and absolute safety but it would certainly seem to be safer than browsing. With CAS we can determine at a pretty low level what we will allow foreign code to do on our computer.
    To me using a browser is like driving a beat up 76 Pinto through a bad neighborhood. Sure, the old Pinto's gotten us where we need to go and the locks still more or less work, but I'd feel a lot safer in a new Mercedes with power locks, security system, and Lojack.
  2. Companies around the world spend tens of thousands or dollars building web farms to house internal and external applications (Hundreds of thousands if you're using Java). We've got massively clustered systems with 2 or 4 Megabytes of RAM, quad processors and hard drives the size of Montana. We have ASP.NET which is arguably one of the biggest leaps forward for web development trying desperately to make web development "feel" like Windows. We have all the effort, thought, and millions of dollars that have gone into building what we now call the Information Superhighway. But with all of that power on the servers, the end result is still HTML.
    As concepts like Peer-to-peer networking, distributed processing, and grids grow in popularity, does it make sense for us to give up on the monolithic web server and look at how to take advantage of the millions of CPUs living at the end of every IP address?
  3. Browser wars again? Now that FireFox has begun to pick up some steam in the browser market, do we really want to go back to the days when different browsers twisted us web developers into knots by rendering the exact same HTML tags different ways? It's hard enough to deal with the changes caused by different versions of the same browser much less different browsers. Now the rumor is that Google is going to step into the ring in the browser free-for-all. When and if they do, creating web applications will become even more tedious as we check and recheck our browser compatibility only to find that FireFox doesn't like the div tag or CSS support in the new Google browser uses top-border and not border-top. Personally I can live without going through that again.
  4. Perhaps the most common theme in all of the technology industry is convergence. We use to have computers on our desktop but we needed to make them mobile so we built luggables, then portables, then laptops. That wasn't small enough so we built PDAs which themselves have gotten smaller and smaller. Everybody has to have at least one cell phone but carrying both a cell phone and PDA is inconvenient so now they are being combined into "Smart Phones". Devices and software are merging into single, do everything machines that not only perform tasks as we request them but do work for us without the need for our interaction. For example, while typing this posting, my PC began recording "The Family Guy" through it's video capture card.
    What this entails is a shift away from the standard request-response paradigm that is center to current browser based applications. As systems become more and more complex we are going to want the work to be done for us without having to trigger it with a request. The browser world doesn't allow for this, instead we "kludge" the solution by causing the page to be requested every X number of seconds. I feel that in the very near future this will become insufficient to support the types of interactive and intelligent applications that our users want to buy and we want to build.
  Message #139240 Post reply Post reply Post reply Go to top Go to top Go to top

Definitions

Posted by: Harris Reynolds on September 22, 2004 in response to Message #138933
In discussions like these there seems to be a fair amount of mixing of terms. What exactly is the definition of a "Smart" client? My understanding of a smart client is that it will just do the right thing based on its current operating environment. If it detects an internet connection it responds in a certain way and if not it responds differently (in some kind of disconnected mode).

Most of the discussion so far has seemed to focus on the standard Thick vs Thin client, with "Rich Internet Apps" being a variation on a theme that tries to capture some "thick" features but still run in a browser.

Smart clients though are another thing altogether in my opinion. They are most easily implemented in a thick environment, but could be implemented via something like Flash with some difficulty.

Interesting discussion though; esp the Rich/Reach stuff in blog land a couple weeks ago. We are still very much in the infancy of web applications.

~harris
http://www.armchairathletes.com

p.s. Glad to see some of the big guns help spice up the .Net version of TheServerSide!!! :-)

  Message #139271 Post reply Post reply Post reply Go to top Go to top Go to top

Network is the key

Posted by: Fran?ois Lemaire on September 23, 2004 in response to Message #138933
Harris, you're right to give the definition of a smart client again, but don't you think that the fact that a smart client can detect the presence of a network connection and work in disconnected mode means that it's a thick client? How do you make a thin client (browser) work in disconnected mode?

I also like the idea that with a browser we're running "unchecked" code on our computer. But look at where security resides nowadays: firewalls and NAT routers. That's why big "distributed" apps (distributed in the sense that data storage and manipulation is in a separate local network than their display and use) are made on browsers. SOA is great; the idea that web services are not just pull model RPC over XML is great; but my computers are behind a NAT router, so the server cannot call them unless I configure my NAT router to do so, and I have to open many exotic ports, at least one per computer (fortunately, I have 20 machines, so I won't run out of ports...). Will network administrators be willing to do it? I doubt it. That's why I think network is the key to this debate. We'll go as far as the network allows us to go, as great and beautiful our apps are.

(Please excuse me for my bad english; you can't hear my french accent, but I can tell you it's pretty thick :))

  Message #139281 Post reply Post reply Post reply Go to top Go to top Go to top

RE: Back to FAT client? No. Forward to Smart Client

Posted by: Philip Stockwell on September 23, 2004 in response to Message #139205
You mention Messenger. Maybe the future is a hybrid of smart fat clients and web look-alike versions, aka: http://webmessenger.msn.com. In fact this web version has some features I'd like to see in the fat client. For example clicking your display name and editing in place, and actually displaying the emoticons in contacts display names.

Its fair to say that this application is one which lends itself to working over the web, but the question in development should be more about would a user need to access this from the web. I can't see Visual Studio in a browser but email and instant messaging are uses which are very useful.

  Message #139300 Post reply Post reply Post reply Go to top Go to top Go to top

Innovation

Posted by: Mike Parsons on September 23, 2004 in response to Message #138933
One of my main concerns about an wholesale move back to Smart/Rich/Fat clients is that it limits the number of people involved in creating innovative solutions. One of the things I loved about the the Browser was that it allowed creative individuals to create new and exciting applications without have to be a software engineer. Not having a complex tool set for creating web pages/apps was almost a blessing since it allowed more "freedom of expression" in designing/developing applications.

Moving back to Smart/Rich clients inevitably means having to learn complex tool sets that "presuppose" how applications are built. By definition, the use of these tool sets also dramatically limits the number of individuals (i.e. software engineers) designing/developing new applications. With browser-based applcations, the number of individuals capable of developing/designing web pages/apps far outnumber the typical programmer. A good example of the type of innovation I am talking about is web-based menuing systems. Just do a google on javascript menus and look at the variety of options available, most of them developed by non-programmers. Now take a look at the equivalent in the Win32 world ... a much much smaller number. That is not to say that one could not develop all web-based menuing systems in smart client technology. The point is that browser-based technologies (i.e. HTML, DHTML, Javascript, etc) made "software construction" available to a much wider audience, hence the greater chance of innovation.

With obvious exceptions, all we are doing with Smart Client Technologies is reimplementing the same old stuff over and over again. Years ago, we had VB 6.0, today we have Winforms, tomorrow Avalon. I can bet that the single biggest usage of these technologies is to reimplement the same application that was done in a predecessor technology. Surely we can find better uses of our time/skills.

Let's not just keep reimplementing the same old stuff ... let's innovate!

  

My point is this




matically This is fine if you want every application in the world to look like Outlook

  Message #139327 Post reply Post reply Post reply Go to top Go to top Go to top

Network is the key

Posted by: Harris Reynolds on September 23, 2004 in response to Message #139271
Frank,

A smart client would not have to be thick in the traditional sense. A thin client could commicate with a local http proxy that detected a network connection. The lowest common denominator on Windows for this architecture would be a professional version of Windows with the IIS component installed. In disconnected mode a Flash UI running in a browser could just talk directly to the local http server. In connected mode it could talk to the live server. Technically the intelligence is actually in the "smart" proxy, but since this aspect is hidden from the end user, it gives the appearance of a smart thin client.

There is obviously a fair amount of complexity in this kind of solution, but it is possible. There was some related discussion regarding this on Adam Bosworth's blog some time back.

~harris
http://www.armchairathletes.com

  Message #139339 Post reply Post reply Post reply Go to top Go to top Go to top

RE: Innovation

Posted by: Chris Sells on September 23, 2004 in response to Message #139300
Except for flowy content, I actually find web clients harder to implement than web clients. State management, session management and building responsive UIs in the face of cross-platform UI generation are all examples of things that are much harder for me in web apps than in windows apps. Plus, I've never been able to build a good web site w/o the help (and expense) of a graphic artist, whereas I can build good looking windows apps all on my own (so long as I "leverage" icons from somewhere : ).

However, if you want innovation, you need look no further than Avalon. While Windows Forms lets you build first class Windows applications, Avalon lets you define whole new UI styles in much the same way that the web does, although with much more functionality than HTML. This is because Avalon can take maximum advantage of the platform and because the platform has gained a ton of functionality over the years.

  Message #139357 Post reply Post reply Post reply Go to top Go to top Go to top

Now that's compicated!

Posted by: Fran?ois Lemaire on September 23, 2004 in response to Message #139327
You're right, it's complicated. And since I would have to tell the user to install IIS and I would have to have him install my software on it, in the end I'd rather use a thick client (and I could put a MSHTML control in it if needed!). For me, thin client is great because you can target any platform with no install. Just my opinion.

Thanks for the reply

  Message #139362 Post reply Post reply Post reply Go to top Go to top Go to top

Back to FAT client? No. Forward to Smart Client

Posted by: Simon Littlehales on September 23, 2004 in response to Message #139202
Huh? Perhaps I've missed something but the last version of HTML to be released by the W3C was in 1997
Paul - think you misunderstood...I didn't actually mention anything about advances in HTML? I was talking about the recent improvements in all browsers' support of web standards ie. DOM, ECMAScript, CCS, XML, XHTML and yes, HTML.
This is thanks to the webstandards.org and the hard work of people like Jeffrey Zeldman etc.
This means the arrival of any new browser these days is a GOOD thing, NOT the beginning of Browser Wars part II. There is no need to use browser sniffers, or write more than one version of a web page any more (OK - not strictly true, but we're very nearly there). This is convergence at its best. Even handheld devices are beginning to support these standards.
I agree, the web is nowhere near as richly interactive as a FAT client, but this will come, unfortunately if we all fork off in the direction of incompatible FAT clients this will be later rather than sooner.
Reading through these posts its obvious that in the meantime most developers should choose to keep up with at least one FAT technology in parallel with their web standards-based apps. I wouldn't want to hedge my bets either way at the moment and choosing one or the other could obviously lead to marginalising oneself.

  Message #139369 Post reply Post reply Post reply Go to top Go to top Go to top

Back to FAT client? No. Forward to Smart Client

Posted by: Paul Ballard on September 23, 2004 in response to Message #139362
No, I don't think I misunderstood, I just disagree :-) Standards are great, but in a competitive market browser makers are going to want to provide some sort of benefit beyond what the other browsers offer and that will require them to break with the standards. Since there hasn't been much competition lately there's been no need to push the envelope of features and instead most of the work on IE has been towards security.

I also don't believe we're nearly as close to the end of browser sniffing as you might think, and if we are it's primarily due to the fact that IE has more than 90% marketshare. As a developer I might not want to invest too much time or money in making sure my website looks good on another browser that represents less than 6% of the market, And if by chance there is a problem then the number of complaints is still relatively small.

Adding more browsers and reducing the marketshare of IE on the other hand will make me once again have to worry about browser compatability, and THAT is a BAD thing.

I'm not sure of the exact numbers but if you consider a world in which IE represents 80% of the market with FireFox and other browsers taking up 20%, that would mean that when I create a web application I have to make extra efforts to support 20% of my users. However, if Windows represents 90% of my market with Linux and Mac taking up 10%, then it would be more cost effective to implement my product as a Rich Client app aimed at Windows and reduce the number of non-standard users I had to support. Again, I'm making these numbers up but the concept is the same. IE's dominance in the browser market is a major argument FOR browser interfaces and introducing more browsers into the market will only dilute this benefit and give further credence to Rich Clients.

  Message #139376 Post reply Post reply Post reply Go to top Go to top Go to top

RE: Now that's compicated!

Posted by: Chris Sells on September 23, 2004 in response to Message #139357
For me, thin client is great because you can target any platform with no install. Just my opinion. Thanks for the reply
My argument is that with ClickOnce and .NET 2.0, the installation step should go away or at least be zero barrier to entry.

  Message #139391 Post reply Post reply Post reply Go to top Go to top Go to top

Disconnected mode, GUI responsiveness/scalability are the keys

Posted by: Jim Sally on September 23, 2004 in response to Message #139169
The beauty of Smart Client apps to me is their ability to work without a network connection, for instance via an off-line cache, and then re-synch once reconnected to the "home network". Take Outlook itself, I never work in connected mode any more, as I find it much more responsive to simply work in off-line mode, and synch as I see fit. I can take my laptop anywhere, and easily access all of the data that I need access to. I can create new things, edit and delete existing things, etc. It's just a much more productive work environment. And without benchmarks to back up my opinion, probably much more "polite" to the general network environment, as it greatly cuts down on the "chatter".

After that, GUI responsiveness/scalability is the second most important factor in chosing Smart Client apps. About 18-24 months ago, I spent a great deal of time "pushing the limits" of DHTML web-client apps using IE5 and IE6. I accomplished a lot and was happy with what I accomplished. I also found out the limits of the technologies. In the end, and using OWA as a very fine example of what I had come up with, "DHTML based super-apps" just aren't as useful as they could be. I'd much rather have an extremely fast, but less functional web app, than a less functional and over-bloated one like OWA. But maybe that's just me...

  Message #139407 Post reply Post reply Post reply Go to top Go to top Go to top

Back to FAT client? No. Forward to Smart Client

Posted by: Simon Littlehales on September 23, 2004 in response to Message #139369
Standards are great, but in a competitive market browser makers are going to want to provide some sort of benefit beyond what the other browsers offer and that will require them to break with the standards.
Sorry - I just don't think that this is happening anymore! The major promponents of browsers like FireFox, Opera, Mozilla etc. are actually the same people that are pushing web standards eg. browsehappy.com
The main selling point of these browsers IS their support for standards and the features that differentiate them are not proprietary markup but interface features. Eg. Firefoxes tabbed windows, Opera's PageZoom etc. MSIE still has proprietary options for the developer, but also supports the standards on top of this. One of Firefoxes main selling points is its speed and small footprint achieved by taking away support for the non-standard stuff.
The whole point of this is that we do NOT exclude users anymore based on their browsers and we don't have to create different code for each one.
I agree we're not there yet - but I think its getting very close.
Its "horses for courses" i s'pose. There are many apps for which the web is just not suited eg. Graphic driven games (!), Design Packages, realtime monitoring etc. etc. But as a method of sharing information and for interaction with the maximum audience with the smallest amount of work I still think the web is the superior platform...but the world is an imperfect place, so yes, i'll still be learning the Smart Client stuff - and probably enjoying it too!! ;-)

  Message #139420 Post reply Post reply Post reply Go to top Go to top Go to top

What about business needs as a factor?

Posted by: Natty Gur on September 23, 2004 in response to Message #138933
I was involved with creating pure web solutions (web system of systems) and smart client applications for enterprises. What I learned is that every one of this approaches got is benefits and flaws. What counts here is the enterprise needs, the wisdom here is to match smart client or web solution for your enterprise needs. I really don’t think that the WEB is going to disappear or slows down for the following reasons:
1) HTML is the cockroach protocol we all will disappear and he will stay. (it’s don box metaphor not mine).
2) Since MS is not the only player in the market other vendors will keep on web development (and Microsoft will follow them…).
3) Another one for Don Box : COM and CORBA failed due to the fact that every one of them ignore the other and since in reality they live side by side they need to tack in account one each other. Well the same works for HTML. HTML is excellent glue, from enterprise point of view, to orchestrate several systems from different vendors as unified solutions. So as long MS suggest solutions that don’t tack in account competitor’s solutions HTML is here to stay.

  Message #139441 Post reply Post reply Post reply Go to top Go to top Go to top

RE: What about business needs as a factor?

Posted by: Chris Sells on September 23, 2004 in response to Message #139420
The beauty of smart clients is that they're best served on a plate of web services. The wonder of this is that once you expose your business logic as a set of web services, you can build platform-specific smart clients or web sites or let your customers build stuff you would never have thunk up yourself. To me, smart clients + web services == mucho goodness.

  Message #139445 Post reply Post reply Post reply Go to top Go to top Go to top

It works for Messenger, yes

Posted by: Bertrand Le Roy on September 23, 2004 in response to Message #139205
Granted, it works for Messenger, but that's a very particular application in that the data itself is distributed over the internet.
If we go back to the example of mail clients, web mail is the only way I can consult my mail everywhere today (except for Exchange-like mail, which most people don't have access to).
Now, the rich applications of the future will probably often have centralized data access for ubiquity and rich clients for the UI (this is the vision behind XAML/Indigo applications, by the way).
Still, web applications are often easier to reach this goal.
I'm not defending web apps as the one and only solution, far from it, but don't discard them too fast.
You should also consider the homogeneity and seamless experience you can have for example when the administration of an e-commerce web site is also a web application written with the same technology.

  Message #139474 Post reply Post reply Post reply Go to top Go to top Go to top

Progress and Innovation

Posted by: Michael Plavnik on September 24, 2004 in response to Message #139339
Progress and innovation are beautiful words… They are also transparent words. But this thread seems full of transparent statements. Innovation for human interaction engineer and systems engineer could be very different things. Some combination of spices in the dish can be real innovation for others. So when one is addicted to new tastes of menu, let one enjoy it. Myself, I observed the same situation with menu and other UI libraries in DOS world between 1987 and 1990.

I know that humans tend to do what they are accustomed to do and what requires less initial effort (why not to skip gym this particular evening or morning?). So for me benefit of particular flavor of UI is a peripheral issue. Microsoft is trying to classify applications in Longhorn and this direction can be very fruitful in the following decade. I would distinct browsing and productive styles of using computers. Myself, I am writing this post in MS Word, and consider it is easier to carry with productive :-) style application. Briefly, productive style care about performance and quality of work during the whole, somewhat lengthy and focused session with tight tools integration. Browsing style for me is related to studying, mostly leaving behind references to follow later and minimum effort to access variety of related information. Checking web-mail once or twice a day can be considered browsing style, while using Exchange / Outlook as groupware collaboration can’t. Mosaic with HTML was hypertext browser, and excellent example of browsing style.

What makes the DIFFERNCE for browser based applications? First, it is incomparable ease for the designer to integrate third party web applications. All you need is web site address. I understand this is not real integration, but for browsing it is enough. Second, hypertext and media presentation abilities are declarative, simple and powerful, and if not completely adequate today, could be evolutionary made so. Third, it is availability/reach of application and incremental access to application's components. Forth, it is easier to type a word and to search than constantly organize workspace (let others work for you :-). In other aspects I regard browser as poor run-time application environment.

Smart client initiative addresses third issue, but as far as I know incremental access to application features has a long way to go. For example, Kinitos dropped it from their platform after several years of development.
Avalon addresses second issue, but I believe that language oriented (visual or not) approach can be more powerful. I remember Microsoft is still marketing CLR
First issue is very difficult, especially, if you want more integration then merely browsing to. SOA and web services are there, but concept is as powerful as assembler and equally expressive. Microsoft and Talligent have much questionably successful experience to share.

Middleware in the user centric world awaits a lot of innovation. Both Java and .NET are often criticized as lacking higher level abstractions, and browser as having limited abstractions.

  Message #139515 Post reply Post reply Post reply Go to top Go to top Go to top

RE: Why CHOOSE ?

Posted by: rory Winston on September 24, 2004 in response to Message #139239
We all complain as one vulnerability after another is found in IE and FireFox
Ahem. I think the graph is skewed waaaaaaaaaay over towards IE on that one.

  Message #139520 Post reply Post reply Post reply Go to top Go to top Go to top

Browser Renaissance

Posted by: Mike Parsons on September 24, 2004 in response to Message #138933
Maybe if this is true, then we will see some renewed interest in browser-based applications ...

"Google is investing heavily in JavaScript-powered desktop-like Web apps like G-mail and Blogger. Google could use their JavaScript expertise to build Mozilla applications. Built-in blogging tools. Built-in Gmail tools. Built-in search tools," one well-known blogger, Jason Kottke, wrote recently.

http://news.com.com/Clues+may+point+to+Google+browser/2100-1032_3-5379625.html

  Message #139542 Post reply Post reply Post reply Go to top Go to top Go to top

RE: Why CHOOSE ?

Posted by: Paul Ballard on September 24, 2004 in response to Message #139515
As is the user base. if 10 people using a product find 1 bug and 100 people using another find 10, it doesn't mean that product 1 is more stable or safe. When FireFox gets the kind of usage that IE does, we can do a non-skewed comparison.

  Message #139568 Post reply Post reply Post reply Go to top Go to top Go to top

RE: Why CHOOSE ?

Posted by: Mehul Patel on September 24, 2004 in response to Message #139542
As developer of apps, and doing stuff for customers, many customers now want support for IE and One Additional Browser. Firefox or Mozilla. So as developer i have to code javascripts for both. So we as developers, and engineers, have to be one level above this CHOOSE/NOT CHOOSE --- I LIKE THIS/DONT LIKE THIS.....war..

It requires very less effort in todays world, with web services and other standards, so we are getting closer to close the difference, and go one level higher, --- we all should aim at giving options to customers. Rather then saying them hey just use IE and you will be fine..

So lets get past this blog war, thread war, its gonna be endless, that much i can promise. We all are very stub-born ;)

Firefox is good, i am impressed, we cannot throw it away. Windows started smaller than mainframe, didnt mean it was bad. IE started later than Netscape Success didnt mean its bad.

So .net came later than java didnt mean its better than java, its just another tool. Tool to serve business, thats all, nothing more, nothing less, so is java. Peace.

  Message #139582 Post reply Post reply Post reply Go to top Go to top Go to top

RE: What about business needs as a factor?

Posted by: Natty Gur on September 24, 2004 in response to Message #139441
Got your point but from global enterprise point of view I believe that there are cases that web applications takes smart clients for their easy ability to integrate different system UI into one window. After all the main diff between smart client and web systems is UI, one use HTML and browser and the other use windows forms. Now as you probably know there is a trend in the IT field to use as much as enterprise forms of data together to enable the end user to gain insight, from the data combination (competitors, Link analysis, GIS, Images, Financial data, etc’). Those user insights from diff data lay down together helps the user to gain enterprise goals. User not just want to see different enterprise data together they also want to control which data in which scenario they want to see on same page. Furthermore the system should enable users to add data views of future systems. What I’m arguing is that HTML is much easier way to achieve this system of systems pattern then smart clients.

  Message #139597 Post reply Post reply Post reply Go to top Go to top Go to top

RE: What about business needs as a factor?

Posted by: Chris Sells on September 24, 2004 in response to Message #139582
Now as you probably know there is a trend in the IT field to use as much as enterprise forms of data together to enable the end user to gain insight, from the data combination (competitors, Link analysis, GIS, Images, Financial data, etc’). Those user insights from diff data lay down together helps the user to gain enterprise goals. User not just want to see different enterprise data together they also want to control which data in which scenario they want to see on same page. Furthermore the system should enable users to add data views of future systems. What I’m arguing is that HTML is much easier way to achieve this system of systems pattern then smart clients.
I was with you when you talked about the need for integrating multiple data sources and displays in innovative ways, but then stopped short when you said that HTML was the easiest way to do that. In my experience, smart clients are a far easier, more flexible, more powerful way to combine multiple data sources. For example, we have a ton of internal HR apps at MS that are web based and while they're great for serving the needs of a large number of people, they suck at focusing on the needs of any one department, especially when I have to take data from one and put it into the other. The easiest way I've found to combine these applications together is with programatic APIs and smart clients to eliminate the wait time going between screens on the web sites and moving data between them.

And, while this has nothing to do with point I'm making, it's taken me about an hour to write this piece because I was doing things in between. The lack of a Save button made me very nervous. Web sites don't have a Save button. Smart clients do.

  Message #139618 Post reply Post reply Post reply Go to top Go to top Go to top

RE: What about business needs as a factor?

Posted by: Natty Gur on September 24, 2004 in response to Message #139597
First I'll be happy to discuss this issue further, If you like.
Anyway my career path include very successful and proven (maybe to most proven in the world) competitive intelligence system. Actually the system is build from different set of systems (around 80) that handle different kind of data and show them to the user dynamically, innovatively and on the same HTML window. Using Iframe or share point seems to me the easiest way to take different data and their visual implementation and group them dynamically on the same window. It’s also the easiest way to enable adding of future systems UI. From enterprise point of view it’s also easy way to combine visualization from different suppliers that use other platforms then MS such as Java.

Those days I’m involved in CI system that it prototype is build with smart client attitude. Regretfully the outcome isn’t CI system. The user got several windows to jump between, we cant integrate dynamically (and in easy way) other system visualization, even if we add other system user control (which isn’t dynamically approach) we have difficulties to jump into the user control system, it is very hard to implement one navigate system that enable the user to jump from screen of one system to screen of other and then back. There are much more problems but as I said in my first post they address specific needs. For other needs smart client could be the perfect match ….
But on the other hand if anyone else managed to build such a system using smart clients first of all I’m willing to learn, second there might be more then one way to solve the same problem…

  Message #139663 Post reply Post reply Post reply Go to top Go to top Go to top

I can't rely on a single client platform

Posted by: Fran?ois Lemaire on September 25, 2004 in response to Message #139597
Web sites don't have a Save button. Smart clients do.
Hmmmm, I'd say this web site doesn't have a Save button. But nothing prevents you from adding one (for example, in Yahoo! Mail, you can save a message you're writing to finish it later). But I'll have to agree with you that it's harder to implement.

By the way, I don't think there's a clear answer to the debate between thick or thin client, smart or dumb client. On the one hand, you can say that achieving a beautiful interface is easier in HTML, though it's not always the case (how do you beautifully make a tree view in HTML, if you want to be standards compliant and not use applets or windows forms relying on a heavy runtime? I've been asking myself this question for 4 years!).

On the other hand, modifying data is easier on a thick client, because custom controls are done more easily, and you can use the local system as a backup for the remote repository, which is the idea behind smart client. But again, you have to rely on a heavy runtime, and maybe this runtime is unavailable for your client (I use applets communicating with my form by javascript to type decorated text in our web based admin, but this doesn't work on most Apple computers. Nowadays, I could make this admin as a smart client using a web service and a local cache, but the .NET framework is unavailable on Apple computers, and Swing is painfully slow and resource consuming)

So, with great reluctance and sadness, I have to use the few functionalities that ALL my clients can run on their platform of choice, because I can't order my clients to dump all their Apple computers to buy PCs, and I can't afford the luxury to refuse clients using Apple computers.

But the idea of smart client is great, and I hope I'll be able in a near future to have a common code base for a web admin and a smart client!

  Message #139670 Post reply Post reply Post reply Go to top Go to top Go to top

Debate: Rich Clients or Browser Interface?

Posted by: Lloyd Benson on September 25, 2004 in response to Message #138933
Personally, I've always liked both. If I have my own desktop around a rich client is nice, but a browser interface is nice too when I may not have access to that rich client.

-Lloyd

  Message #139931 Post reply Post reply Post reply Go to top Go to top Go to top

That's your argument?

Posted by: Shannon Hager on September 27, 2004 in response to Message #139376
...thin client is great because you can target any platform with no install.
My argument is that with ClickOnce and .NET 2.0, the installation step should go away or at least be zero barrier to entry.
ClickOnce will not "target any platform with no install" so where is your argument?

  Message #140017 Post reply Post reply Post reply Go to top Go to top Go to top

Recent Survey

Posted by: Mike Parsons on September 28, 2004 in response to Message #138933
According to a recent programmer survey by Infoworld (What do developers want?)

http://www.infoworld.com/article/04/09/24/39FErrdev_1.html?s=feature

when asked ... "When your software presents a user interface, what is your airganization's perferred technology?"

50% said Web Style (DHTML/HTML/JavaScript)
24% said Fat-Client GUI (Windows/Flash/Java/Swing)
18% said Thin-client(Remote) GUI

Based on these results, it would seem rational that we invest more in making it easier to develop Web Style Applications.

  Message #140061 Post reply Post reply Post reply Go to top Go to top Go to top

That's your argument?

Posted by: Natty Gur on September 28, 2004 in response to Message #139931
Furthermore Clickonce is still depend on MIME filter on the client. if for some reason that MIME filer remove nothing will be download to the client...
Regretfully I saw more then once that .NET MIME filter suddenly disappear... It doesn't surprise my though since the MIME filter is still based on DLL hell. Yes, the same DLL hell that MS told us to be aware of....

Maybe we will see solution in Longhorn but until then ....

  Message #140076 Post reply Post reply Post reply Go to top Go to top Go to top

That's your argument?

Posted by: Mike Parsons on September 28, 2004 in response to Message #140061
I am curious how different ClickOnce is from this Java WebStart ...

http://java.sun.com/products/javawebstart/

This technology have been around for quite awhile but it never received any real traction.

Comments?

  Message #140095 Post reply Post reply Post reply Go to top Go to top Go to top

That's your argument?

Posted by: Natty Gur on September 28, 2004 in response to Message #140076
Oh boy! They've got it since 2001 .... Java(TM) Network Launching Protocol &
API Specification (JSR-56). Thanks I didn't know that.

Its just a proof of MS marketing abilities ...

  Message #140286 Post reply Post reply Post reply Go to top Go to top Go to top

That's your argument?

Posted by: Chris Sells on September 29, 2004 in response to Message #139931
...thin client is great because you can target any platform with no install.
My argument is that with ClickOnce and .NET 2.0, the installation step should go away or at least be zero barrier to entry.
ClickOnce will not "target any platform with no install" so where is your argument?
Agreed. ClickOnce will only target platforms with .NET 2.0 on them, but those you get with "no install."

  Message #140287 Post reply Post reply Post reply Go to top Go to top Go to top

That's your argument?

Posted by: Chris Sells on September 29, 2004 in response to Message #140076
I am curious how different ClickOnce is from this Java WebStart ...http://java.sun.com/products/javawebstart/This technology have been around for quite awhile but it never received any real traction.Comments?
I've played some with Java WebStart and the technology is similiar to No-Touch Deployment in .NET 1.x and ClickOnce in 2.0, although I find it "clunky" (although as a Windows man, you might not find that surprising : ).

  Message #140291 Post reply Post reply Post reply Go to top Go to top Go to top

re: That's your argument?

Posted by: Chris Sells on September 29, 2004 in response to Message #140095
Oh boy! They've got it since 2001 .... Java(TM) Network Launching Protocol &API Specification (JSR-56). Thanks I didn't know that.Its just a proof of MS marketing abilities ...
Actually, I think MS has done a terrible job of letting developers know about No-Touch Deployment in .NET 1.x, but I think we're finally getting our act together with ClickOnce in .NET 2.x.

  Message #140306 Post reply Post reply Post reply Go to top Go to top Go to top

re: Recent Survey

Posted by: Chris Sells on September 29, 2004 in response to Message #140017
According to a recent programmer survey by Infoworld (What do developers want?)http://www.infoworld.com/article/04/09/24/39FErrdev_1.html?s=featurewhen asked ... "When your software presents a user interface, what is your airganization's perferred technology?"50% said Web Style (DHTML/HTML/JavaScript)24% said Fat-Client GUI (Windows/Flash/Java/Swing)18% said Thin-client(Remote) GUIBased on these results, it would seem rational that we invest more in making it easier to develop Web Style Applications.
I agree that a lot of IT organizations are building web UIs. The much more interesting question would be to ask the users which kind of UI that they prefer to use.

  Message #140387 Post reply Post reply Post reply Go to top Go to top Go to top

re: Recent Survey

Posted by: Mike Parsons on September 29, 2004 in response to Message #140306
I agree that a lot of IT organizations are building web UIs. The much more interesting question would be to ask the users which kind of UI that they prefer to use.
Hey Chris ... would you not assume that these apps are based on requirements from users??

  Message #140421 Post reply Post reply Post reply Go to top Go to top Go to top

Bosworth's Opinion

Posted by: Mike Parsons on September 29, 2004 in response to Message #138933
I think Adam has some real insights relevant to this discussion ...

"My mother never complains that she needs a better client for Amazon. Instead, her interest is in better community tools, better book lists, easier ways to see the book lists, more trust in the reviewers, librarian discussions since she is a librarian, and so on."

http://www.adambosworth.net/archives/000026.html

  Message #140428 Post reply Post reply Post reply Go to top Go to top Go to top

Smart browsers rather than smart clients

Posted by: Gerke Geurts on September 29, 2004 in response to Message #138933
The main attraction of native clients (smart, thick, rich, whatever...) to me are the rich visual application frameworks that make the design and programming of user interfaces a pretty smooth experience.

Though current bowser technologies (DOM, CSS, JavaScript, XML support) provide a very solid foundation for building such a framework for the browser, I am not aware of much activity in this area. Where I have seen it, I have been impressed with the result. Rich widget libraries, drag & drop, strong eventing model are all possible, but it takes someone to write the underlying framework.

I can imagine why Microsoft is not keen to invest or promote such an approach, as it would undermine their stategy for the Windows and Office client products. But I can also see that a rich, web standards based, browser-side framework is a much better bet for most enterprises: less worry about client platforms (and tie-in to any particular vendor), easier deployment, standard UI approach regardless of development environment.

The advantages of loose coupling don't just apply to the backend. They are equally relevant for the front-end. Who can guarantee that Windows will stay the norm? If Microsoft deems it appropriate to worry about the alternatives, the forward-looking enterprise should as well. Using the web in a smarter way than we do today seems a viable insurance policy to me.

  Message #141368 Post reply Post reply Post reply Go to top Go to top Go to top

Smart browsers rather than smart clients

Posted by: Mike Sabot on October 05, 2004 in response to Message #140428
After reading the this thread, I do believe every one has forgotten one thing, its called the real world.

Except for the deployment issues with a rich client, in the real world rich clients surpass smart clients when it comes to performance. I say this from both a personal point of view and the applications I support in 89 countries. I have learned to play solitare at home while I wait for my internet application to change pages. Living in a rual location, with no high speed internet connection availabile unless I wish to fork over $800 for Sat equipment + $60 month fee, I live with 32k dial up connection. In some of the countries that I support, getting electricty and phone connections at the same time can be a problem. Many places are still using the old sneaker net (for those that don't remember thats transfering data via floppy from one computer to another).

In the real world there are still many places were smart clients just won't work....

  Message #141371 Post reply Post reply Post reply Go to top Go to top Go to top

re: Recent Survey

Posted by: Scott Lorenz on October 05, 2004 in response to Message #140387
I'm not Chris, but - No, I wouldn't make that assumption. Users don't make that requirement. In fact, in my experience users will never choose browser-based apps over thick client apps, assuming they know the difference.

That issue aside, the choice of browser-based vs. thick client is generally made for non-usability reasons. I'm coming from an enterprise development environment, not the shrinkwrap world, where software distribution and maintenance across the enterprise are huge concerns for everyone and have a huge impact on how we develop our enterprise support solutions.

We have several "smart" client apps, but the vast majority of our support software is browser-based. We choose the best solution based on the purpose of the software taking into account the distribution and support solutions required to support it. In most instances distribution and end-user support issues overrode all other factors in the decision.

One of the costs that Chris Anderson didn't mention was the cost of support, which is much higher with thick-client apps. That support cost is much closer to zero with browser-based applications than with thick-client apps.

  Message #141372 Post reply Post reply Post reply Go to top Go to top Go to top

Smart browsers rather than smart clients

Posted by: Mark Wilson-Thomas on October 05, 2004 in response to Message #140428
I am not convinced that the fact the platform you are building on "may not be there forever" is a sufficient argument against doing smart clients/in favour of thin client web applications. I think there are some really good reasons why it's of benefit both to end users and those paying for development projects to consider the smart client approach, particularly if you have a standardised client platform in place (e.g. in a large corporate):

1. Web browsing is inherently stateless, yet web app developers inveitably spend a lot of time (and therefore money) coding applications with inherently stateful metaphors, because that's what users want. This is where a lot of time and effort is always spent in a thin (browser based) client development project. No matter how smart your widget library and development IDE is, you will always (even if it is "under the covers") be working around this fact of HTTP life. A smart client does not need to deal with this problem all the time and as such can give a significantly better experience to the end user, often with less lines of code to test and maintain.

2. An HTML based browser application can never be as fully responsive to user input as a smart client can. Can you honestly tell me that you would be happy to do all of your day's work in a web browser? They are fine for single-task, "done in five minutes" activities like ordering a book or pizza, or sending out a quick email, but anything much more involved is just much too painful!

3. As a practicing web UI developer since the v3 browser generation, I also don't believe that browsers have now fully stabilised and converged around all the important aspects; anyone who has tried, for example, to do meaningful DHTML based, drag-and-drop UIs across multiple browsers even in a "post v6 generation" world will attest to that. So I would contest the notion that current browsers are a solid foundation for building a rich visual app framework and suggest that there's a good reason why such frameworks have not become popular. I'd agree things are better than they were back in 2000, but not as much as you might think! This lack of convergence shows up in cost of development and test.

4. It's very hard to make anything more than a static content delivery HTML application work when it's not connected to the web server. Occasionally connected apps are just very hard to build in HTML. And yet occasionally connected is an important mode of working for many people these days (not just geeks either - think of the mobile worker community; how many people work on laptops or other occasionally connected devices these days?).

So I say, roll on the smart client, for the sake of the end users and the budget managers of IT projects!

  Message #141430 Post reply Post reply Post reply Go to top Go to top Go to top

re: Recent Survey

Posted by: Chris Sells on October 06, 2004 in response to Message #141371
In most instances distribution and end-user support issues overrode all other factors in the decision.One of the costs that Chris Anderson didn't mention was the cost of support, which is much higher with thick-client apps. That support cost is much closer to zero with browser-based applications than with thick-client apps.
When deployment and code update are taken out, what other costs of maintainence are there for smart clients that aren't also present for thin clients?

  Message #141464 Post reply Post reply Post reply Go to top Go to top Go to top

re: Recent Survey

Posted by: Mark Wilson-Thomas on October 06, 2004 in response to Message #140387
"would you not assume that these apps are based on requirements from users"

I think this is not quite right. I believe many in-house applications are based on requirements, most certainly. But not necessarily requirements from (end) users! At least as strong a voice in determining the requirements for such apps comes from the IT department, who have long held a marked preference for the perceived lower cost of ownership of a pure HTML web app vs a richer client.

This perception was undoubtedly usually correct in 1998. The choice on offer to most at that time was HTML web app running on a v3 generation browser, or thick Win32/MacOS/etc client with a full installer, DLL hell etc, and the call was obvious. Even if the users preferred the thick client application, the total cost of ownership was prohibitive and the IT department would (rightly) veto it on cost grounds. I think that cost equation is now changing - the rise of simplified deployment for richer clients (e.g. OneClick) means that the question of deployment (especially in a corporate) is not the overriding question it once was. That means users might get the richer client they want and IT might be able to say "yes" because the cost equation starts to make sense again.

  Message #141584 Post reply Post reply Post reply Go to top Go to top Go to top

Smart client technology definitely has its own niche

Posted by: jean hibbert on October 06, 2004 in response to Message #138933
Smart client technology definitely has its own niche.

- If you're building a business application that requires a rich user interface.

AND If you would like to access distributed data storage devices over the internet from within an organisation where the different departments are not necessarily a member of the same LAN.
[.NET provides security mechanisms for soap messaging]

AND Smart clients(Windows forms applications) are in my opinion quicker, easier and simpler to develop than web clients that require the same functionality(Especially if you use the Visual Studio IDE).

Bear in mind that the mono project(www.mono-project.com) should HOPEFULLY someday provide us with the ability to leverage ‘ClickOnce deployment’ on the Linux platform (and maybe a decent IDE)....

  Message #141788 Post reply Post reply Post reply Go to top Go to top Go to top

re: Recent Survey

Posted by: Scott Lorenz on October 07, 2004 in response to Message #141430
Maintenance of the application isn't the main issue. Its supporting the applications running on end-user machines. While that sounds trivial, it isn't. Installation, setup and general "I don't know what I did but it don't work" support for 1000+ users is costly. Going with browser-based applications makes this cost practically disappear.

  Message #141838 Post reply Post reply Post reply Go to top Go to top Go to top

Fundumental Similarity

Posted by: Andrew Miadowicz on October 07, 2004 in response to Message #138933
Watching this discussion grow for a while I can't help but wonder if I am the only person who sees smart clients and browser clients as fundamentally quite similar. What I mean is that, although in appearance, functionality, flexibility, maintainability, etc., etc., etc. they are obviously different, the basic paradigm is surprisingly similar, especially when we start talking about managed runtime environments for smart clients.

Most of the participants make a claim that by writing web application we can reach a much broader spectrum of customers. Well, that's true. What we tend to forget is that this is only true because we currently have those big fat pieces of software, i.e. web browsers, already installed on the users' computers. The browsers in turn depend on the operating system they run on, their components, etc. Essentially, the web browsers are quite sophisticated runtime environments that we run our web applications on.

Now, if we consider the managed runtime environments such as JVM or CLR, we get in principle the same thing, i.e. a runtime environment on top of an operating system. There is really no reason why these environments could not become as ubiquitous as browsers are now.

The big difference to me is the capability and flexibility of these two types of environment. Much can be said about creating user interfaces in a declarative fashion, and W3C standards have come a long way, but we can probably all agree that it's really hard to create dynamic responsive web apps without some amount of java script. Consequently, we don't stick do declarative UI alone, and resort to imperative programming.

And here is where the power of managed runtime environment lies. They give us, developers, all the features and flexibility we care to use. We don’t have to work around stateless protocol issues, lack of out-of-the box controls providing rich and consistent experience, and so on.

So the bottom line for me is: if we rely on a principally the same paradigm, why settle for the limited environment of a browser, when I get the power and flexibility of a managed programming language? Perhaps we should put our efforts into proliferating virtual machines and/or CLRs…

  Message #141860 Post reply Post reply Post reply Go to top Go to top Go to top

The big picture

Posted by: Rajesh Hari Parsad on October 07, 2004 in response to Message #139169
Seem to have missed this one and reading it quite late.

This argument is one that we cannot argue just from a client perspective. All clients interact with a server as well. Clients are becoming more powerful, yet we continue adding stress to the data centre.

For high volume interactivity ... let us consider an integrated CRM and POS solution, where do you want all the logic to reside? Serverside … lets think 2000+ concurrent users. Rich client interfaces with client side sort, simple query, validation etc. type functionality …

[start interaction] -> [data fetch] <task>, <task>, <task> [close interaction] -> server update.

The more you can do on client-side, the more you can defer the capex, as compared to procuring massive servers.

Then you have the scenarios where connectivity isn’t broadband based. Updates and deployment are naturally an issue but very interactive “smart apps” are even a pain on dial-up. Using thin clients are nearly impossible.

This becomes a function of budget and end-user functionality.

  Message #155351 Post reply Post reply Post reply Go to top Go to top Go to top

мишка, привет

Posted by: julia prokulevich on February 03, 2005 in response to Message #139515
Мишка, привет ! Не прошло и ста лет, как появился шанс обнаружить тебя в этом мире. Если это действительно ты:)), то отзовись..
Юля

  Message #155353 Post reply Post reply Post reply Go to top Go to top Go to top

АУ!

Posted by: julia prokulevich on February 03, 2005 in response to Message #139474
Мишка, привет ! Не прошло и ста лет, как появился шанс обнаружить тебя в этом мире. Если это действительно ты:)), то отзовись..
Юля

  Message #333426 Post reply Post reply Post reply Go to top Go to top Go to top

I just wanna say - I was right

Posted by: Simon Littlehales on April 26, 2010 in response to Message #139169
Smug :-)

 
New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET

DSLs and language interop

Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.

VS 2008 Resources

SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.

VB code downloads home

VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.

XAML Learning Guide

Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]

Company uses VSTS DB edition to tame workflow

One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts. (June 24, Article)

Book: Intro to DSL Tools

Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage. (June 24, Article)

I See the Silverlight Shining!

Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server . (June 18, Cartoon)

A look at .NET 3.5

Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps. (June 29, Podcast)

Venkat Subramaniam on AJAX

Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience. (June 25, Tech Talk)

Building a Claims-Based Security Model in WCF - Part 2

In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier. (May 24, Article)

Introducing the Entity Framework

Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year. (May 10, Article)

WCF Security Learning Guide

Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information. (April 24, Article)

Brad Abrams: Patterns for successful ASP.NET AJAX development

TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks. (April 11, Article)

Building a Claims-Based Security Model in WCF

In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services. (March 29, Article)

Authoring workflow using XAML

Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition. (March 22, Chapter Excerpt)
News | Blogs | Discussions | Tech talks | Patterns | Reviews | White Papers | Downloads | Articles | Media kit | About
All Content Copyright ©2007 TheServerSide Privacy Policy
Site Map