Steve: Developing on the Edge - Why rich clients are losing
Steve: Developing on the Edge
Thoughts on development, Web-services, technology and mountains.
10Mar
Tue2009
Why rich clients are losing

My calendar reminds me that I haven't said anything bad about outlook for a while. That's my google calendar, the one that not only brings up a popup in my browser, it texts a message to my phone 10 minutes before the appointment is due. If I had it in outlook, my phone would remind me 24-36 hours after the event, "you had an appointment, but you missed it, as windows mobile is useless at timely reminders".

Here, then, is the complaint. I have received a message with a spreadsheet, so I double click on the attachment to view it

The way outlook is set up, everything is cached locally. Opening a spreadsheet is a matter of saving the attachment to a local file, calling ::ShellExec(). Which may be what Outlook is doing. Sadly, it is doing it in the foreground thread, and the entire GUI is now hung until Excel starts up. Which is long enough for me to get bored, switch out the VM, bring up the Gimp, grab the screen shot and start cropping it before Excel 2007 finally decides to open a 50x4 spreadsheet and so return liveness to Outlook.

In theory, rich client applications should offer a richer GUI than web browsers, and so provide a better user experience. In practise, they don't. Why then, pay for the premium hardware and software needed to run them? That's going to be hard question to answer in today's economy

Comments

"Cloud" applications will win outreply to this thread
On 10 March 2009 at 12: 10 Ben Werdmuller commented:
It's easy to see how "cloud" (i.e., web) applications will win out over the next couple of years.
There's definitely still a market for involved desktop applications, and will be for some time to come - but it's going to be limited to involved, professional activities (video editing, serious number crunching) rather than everyday tasks like those provided by Outlook. And even those may eventually fade away.
It's a new frontier, really, and an exciting one - the question for me is whether the connectivity is actually there to support it.
Wake up and smell the coffee (both at the same time)reply to this thread
On 10 March 2009 at 12: 32 danny commented:
There's definitely still a might gap between expectation and reality when it comes to multi threaded M$ desktop
applications.
With todays multi cored desktop PC's well capable of true multi-tasking its a cry shame that we're still denied the benefit because of sloppy design &| programming.
I would bet that sometime in the past someone once dismissed the need to implement it properly as too much effort for too little gain, what a shame.
but why are they so bad?reply to this thread
On 10 March 2009 at 12: 51 Steve Loughran commented:
I agree with Danny's point that they could be better. but given they are so awful, Ben has a point. client-side apps can offer so much: high bandwidth to the user, the filesystem, local FS access, local device access, decent off-line.
why then is the office suite (and the openoffice equivalent) so uninspiring that google apps are often as good as them? I think one issue is it is that much harder to do a good client app -all the testing and support costs- and the UIs get neglected. Mediocrity is all that is left. We get what is easy to code, not what is needed.
Senior Software Developerreply to this thread
On 10 March 2009 at 16: 20 Keith Bennett commented:
It's unfair to criticize rich client apps as a general strategy due to Microsoft's (or anyone's) poor implementation of them.
The use case you describe requires something that's running all the time; a client app that can be reasonably expected to be on a laptop that's often sleeping would obviously be a bad place to put this functionality. OTOH, there's no reason why a desktop app can't communicate with a (constantly running) server that can send out those notifications.
Java Swing has a steep learning curve (to use it correctly), but is an excellent tool for cross platform rich client functionality. Intellij Idea is a good example of that.
- Keith Bennett
On 10 March 2009 at 16: 22 Keith Bennett commented:
Sorry the title was for the article, not me. ;)
It should have been:
Unfair Comparison
- Keith
But you didn't answer why..reply to this thread
On 10 March 2009 at 18: 25 James E. Ervin commented:
I agree with the complaint registered in this blog posting. But I am confused, why would an AJAX or non-Rich Client App be immune to this problem? I mean doing stuff in the UI thread you ought not be doing is something that should be drilled into anyone doing UI programming. Is it cultural or something inherent in non-Rich Client development that solves this?
"Inquiring minds want to know!"
-- from and old National Enquirer commercial
On 10 March 2009 at 22: 02 Steve Loughran commented:
I think the reason I think the rich apps are doomed is that they don't deliver the value they promise. They promise rich OS integration, better UIs and offline support, but instead the OS integration is so hard that it gets in the way of everything else -at least from a development perspective. It is because a rich app can support drag and drop, fancy OLE stuff, offline filesystems that marketing says "your app must do ...", which leaves the developers trying to add these features and come up with a UI that makes approximate sense. Then there is the problem of dealing with support calls related to all the versions of windows out there. If you target firefox, safari and other up to date browsers (i.e. not IE6), testing is much easier (ignoring configuration options like screen resolution, minimum font size, etc), and you get way less support problems. It is precisely because there is no native OS integration, that you don't have that on your feature list, your development schedule and the test plan.