Technologies like dreamweaver mx and SVG will further help thin clients. Does developing rich client uis still make sense

sudarshan
Saturday, August 3, 2002

Now, you're an employee of that company, trying to find a clever way to generate some traffic to them, right?

Anon. Coward
Saturday, August 3, 2002

It doesn't work with Mozilla so it's not an advantage if you want my business.

vanguard
Saturday, August 3, 2002

Your example is a rich client UI. It is just downloaded every time it is used. It's a bit sluggish and does not work exactly like Outlook, but I'm sure it could be made to if the developers had been more aware of the details of Windows UI interaction.

The boundaries between "rich client" and "thin client" are going away with .NET. In .NET you can develop a"real" rich client (as opposed to an "emulated" one in DHTML) and still have the installation free deployment benefit (once the framework is on everyone's computer of course.)

The main disadvantage I see in rich clients written in DHTML is the complexity in designing such applications. It looks almost as good as a real application on the surface, but how long did it take to write?

Big B
Saturday, August 3, 2002

This is good question!

First, that is a *very* nice web interface. I have seen a couple of web based email applications, and I would venture to say that it was purchased from that company. Regardless, it is nice and users can instantly figure out how to use the application (due to their internal model and concept of a email client).

This idea of purchasing a web email client for local internet providers brings up a very import point:

<point>
That local ISP now will not require it’s users to work with, or rely on Outlook Express, or even Outlook. This could spell a change for software market. This means that most software today *should* have a thin client means of operation built in. (other wise, you will lose out to a competitor that does have this feature!).
<point/>

As for creating a rich web interface, and not relying on the browser, I have one word to say:

D U H !!!

Just about everyone from Oracle to zooba zooba has figured out that one. They all now download a small client that *INTERPETES* commands to a nice interface, and do not rely on any type of html garbage interface. To be fair, that small client applet might crank out html for the browser, but I care less about that fact then if you are using a LCD monitor, or a CRT. This is not stuff the developer needs to worry about (again, we don’t send html down the wire in this case..but a bunch of optimized drawing codes).

What the developer *does* need is a means to send the *output* of a application to a window. That window might be on the local pc, or a pc half way across the world. Hence, build the nice rich interface with your favorite best development environment, and then have it interpreted at the other end. Unix and X-windows (or tele-net for that matter) worked this way from day one.

Ok, now pop question:
Why did Microsoft not go this route when everyone else from Oracle to FileMaker, to Claris to the above OddPost.com has figured this one out?

If you don’t think Microsoft asked this question...then we are on the wrong planet. They HAD TO have asked this question! So, what was their response?

First, we all know that MS does have a thin client technology right now. So, I could be real blunt here and say why is everyone trying to write software that works over the web with a rich interface when we already have Windows Terminal Server from MS? Why is anyone even asking about thin client when it is already available from MS. Why even bother to re-write for the web when RDP is now shipped with every copy of windows?

Terminal Services for those of you who have not seen this AMAZING technology, is simply a means to run the windows interface across a network connection, and that includes the web. In other words, Microsoft already includes a protocol that allows a rich interface across a low bandwidth connection. Perhaps my only gripe with this technology is that is not based on a application window...but only the whole desktop window. The remote desktop support in windows-xp is based on this..and it rocks! (it runs absolute circles around old concept stuff like pc-anywhere, or VNC).

I use TS a lot, and it is great. Why in the world I can NOT attach my applications output to a particular *window* socket is beyond me, but regardless, MS does have a fantastic thin client technology. I have a few clients using TS on a ms-access application between two cites. On both ends they use cheap high-speed net. Users in either city cannot tell the difference in speed and usability, despite the fact that the stuff runs from my City.

Ok, so now we know that thin client has existed for MS. So now we know that you have zero reason to re-wire your software for the web, since again MS has thin client. You can deploy your windows application to the web tomorrow, and not have to re-write one line of code. I done this many times.

Since this ability is available to everyone, then why bother with .net?

The answer becomes obvious:

Imagine that when you turned on your computer it booted Directly to Excel. Excel is the *only* thing that it does. Problem is, that Excel AS A SINGLE STAND ALONE product has little value!

. The fact that you can paste data from Excel into ms-word gives Excel value. The fact that you just filled a nice Excel spreadsheet from running a complex report in ms-access gives Excel value. The fact that you click on a button in your Decision Support system, and Excel is filled with some cool data from the corporate sql server gives Excel value.

It is this inter-operability that gives software its value. Hence, the fact that I can have a nice File-Open dialog pumped across the web is not a big deal (and as mentioned...just about vendor has this now anyway!). The real issue then is not thin client, but a means to extend inter-program communication between web based applications. This is where Microsoft is going, and thus explains why thin client was not adopted as a main strategy.

The problem with the above mentioned email client example is that is does not integrate into my OutLook contact list. Thus I now need to have two contact lists! The other problem is that the above example client can NOT be used by my software is send a email. I can easily do this with ms-outlook. If you every done any work for a company, and they ask:

"I need to press a button, and send this report to.....”

You will understand what I mean, Thus, that email client that the original poster mentioned is useful to check your email. Start developing applications for a company, and you will see that that Email example is of no use to them....*except* for Email. Just like the single minded pc that only runs Excel!

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@msn.com

Albert D. Kallal
Saturday, August 3, 2002

Albert - bravo!

Troy King
Sunday, August 4, 2002

Definitely Albert... BRAVO!!

Our industry goes in cycles. Each time around the cycle, the next "new" technology is given a new name (buzzword) so that we don't recognize we are trying once again to solve a problem we couldn't solve previously.

E.G. A thin client is no more than a return to "dumb terminals" of the mainframe that offered the benefit of not having to distribute executables. A thick client is no more than another attempt to offload processing from the mainframe (i.e. server) and maybe we will be able to solve the distribution problem this time. The applications are still stovepipes - not "talking" to each other.

We have an uncanny ability to ignore the real problems.

Joe AA
Sunday, August 4, 2002

Client-side standard implementations are very compelling. Odsspost style UIs can be built for Mozilla but still would require browser-specific code.

The important point is that the standards are there and implemented. There is enough common functionality to do some really nice stuff. And with XMLHttpRequest, traditional client-server style apps are possible (without multiple frames like we used to do).

But client side DHTML/XML/XSLT etc. are not the RAD cross-platform UI answer to all problems. Performance, browser compatibility and unncessessary complexity are the same problems we faced with 3.x and 4.x browsers. You just get a lot more function for your effort these days.

Standards rule....but they are not a panacea.

"Dan Sickles"
Monday, August 5, 2002

For such an "AMAZING" technology, Windows Terminal Server, it's been around a long time in a product called the X Window System. Which by the way allows you to run only one app and not the whole desktop if you wish.

anonymous
Monday, August 5, 2002

Thans anon, I was going to post that myself but couldn't be bothered. Also available on Windows of course - http://www.cygwin.com

phooey
Tuesday, August 6, 2002

This isn't DHTML, it is all done via ActiveX controls. This means it will only run on IE, and it is already a rich client UI. It would be much more impressive if it were written in DHTML because then at least it wouldn't be limited to MS browsers on MS platforms...

Frank
Tuesday, August 6, 2002

Frank, it *is* DHTML... just that's it's MS interpretation of DHTML (which was way ahead of Netscape when it 1st appeared).

If it were ActiveX there would have been a download dialog asking if you wanted to trust the control.

Dunc
Tuesday, August 6, 2002

Read the source. The display is all DHTML, but it uses ActiveX for the client-server communication. The controls are already on your machine and trusted (thanks to MS), so IE doesn't tell you about them.

Brian
Tuesday, August 6, 2002

In addition to Mozilla, there are a handful of players in the beyond-the-browser space right now. As I see it, the following products make up the pack:

Before you scoff, these products do offer capabilities that go beyond a browser tricked-out on DHTML; fully network-aware, cross-platform, some have tiny runtimes. I've used Rebol extensively and can attest that it provides rich, native-app style interactivity in a minimal footprint-- the sort of stuff that can't achieved in a browser without headaches (plug-ins, complex hacks, compromises).

IMHO, rich client UIs have some meaningful advantages, mainly when high-response, interactivity and data manipulation are required. However, this edge is mostly wasted in the context of general web use-- i.e., basic content distibution and passive consumption.

The upstarts listed above have been tilling this soil for several years now. When M$ .NET eventually enables fully network-aware rich client apps, the industry media and IT world will finally get it. I can hear it now,"Ooooh... Expedia is so much faster and more interactive... it no longer uses a browser... this must be what 1 degree of separation means. MS is really back to its trailblazing roots."

Dusty Bottoms
Wednesday, August 7, 2002

The ONLY advantage a thin-client approach had was the single point of management. Since management centralization is becoming more and more the norm in rich-client environments, the thin client will re-disapear (is that a correct term?), just like its parent, the terminal, for all but some very niche applicatioins.

In response to the distinction between "rich clients" and "thin clients" and how .NET can now produce rich clients that are just like desktop apps, I have looked around for a while now, and I think Bevan is right, Altio is miles ahead of everyone else and is the only mature Java/XML answer to .NET's proprietary C#/XML.

There a loads of DHTML solutions out there that are pretty good as well, but they all have little connection to the back-end apps and browser compatibility is a challenge...plus a lot of them you are writing everything manually from scratch.

Joe Mack
Thursday, August 15, 2002

Nexaweb is also worthy of checking out. www.nexaweb.com
I do not work for Nexaweb.