Fog Creek Software
Discussion Board




The future API is HTML

I think that just about hits it right on.

Case in point.

I run a dance studio in my spare time. Up until recently, we managed things like course registrations, studio bookings, etc. with a desktop database and spreadsheets. Our receptionist had to be physically in the studio to do all of that stuff.

After some months of development, we now have a .net web app that takes care of managing all of the above. People who want to reserve the studio simply log on from home and reserve. The course lists are tied to the online registrations. Even our voicemail is now completely webified. Our receptionist is going home for the rest of the summer in another province, and she will still be able to do her work, all remotely, with no hassles of setting up her parent's 6 year old computer with some sort of rich client. (She wouldn't know how, anyway!)

Obviously we're just a tiny portion of the economy, but if something like this can help us to such a huge degree, it's bound to help bigger companies also. Web apps just make people's everyday lives _easier_, and that's what it's all about.

Lindy
Wednesday, June 16, 2004

One other thing that makes it a no-brainer, is that people do not need to be trained to use a browser. Even elementary school children know how to use a browser. If your web app interface is intuitive enough, anybody can use it in a matter of minutes.

Right there is a huge amount of time == money saved.

Lindy
Wednesday, June 16, 2004

"If your web app interface is intuitive enough, anybody can use it in a matter of minutes."

If your app interface is intuitive enough, anybody can use it in a matter of minutes. The fact that it is a web app has very little to do with this.

Just me (Sir to you)
Wednesday, June 16, 2004

I once ready that the only interface that is intuitive is the nipple.

I think you mean "if the interface is readibly understandable".

Ken Ray
Wednesday, June 16, 2004

I don't think even Rich Client advocates claim that Rich Clients are always better.  If you've got simple needs then it's simple to create a web app that has a simple interface and makes everything simple for the user.  It's when the application becomes more complex that richness of the Rich Client shows its advantage.  I agree with Joel that that advantage is disappearing.  But, for now, it's still definitely there.

". . . she will still be able to do her work, all remotely, with no hassles of setting up her parent's 6 year old computer with some sort of rich client. "

Well, a properly done Rich Client is "zero configuration", you download it from the internet and run.  There is no hassle of setting it up.  You may need to enter a URL or IP address to get things started off.  But that's about it. 

Herbert Sitz
Wednesday, June 16, 2004

I think Joel's example of e-mail clients is pretty instructive actually. For several months I was using Outlook from home (over DSL) to access my Earthlink e-mail account. I did my normal e-mail related stuff and it worked ok.

However, I recently started using Earthlink's web-based e-mail system. I happened to use it once to check messages when I was traveling or something. To my surprise, it turned out to not only do everything I needed to do (much less than Outlook provides) but it actually did it faster! Don't know why, but it does.

That one experience has really made me sit back and re-think a lot of preconceptions.

Jeff Kotula
Wednesday, June 16, 2004

I am with Joel on the rich GUI vs web GUI: 1) I love rich; 2) I am astounded that people are so willing to tolerate thin GUI.

It seems to me that a good work-around strategy, for Microsoft to preserve some backward compatibility, would be to encourage/facilitate dual-boot options. Imagine if a brand-new Avalon/Longhorn machine included a separate Windows XP legacy environment, and an easy dual-boot ability.

I know it is a work-around, but seems like it might have some legs...they would have to make it really smooth, because there is end-user complexity to deal with...

Erik Neu
Wednesday, June 16, 2004

"I am with Joel on the rich GUI vs web GUI: 1) I love rich; 2) I am astounded that people are so willing to tolerate thin GUI."

What do you mean you're with Joel? On the one hand Joel states that there are some apps where the rich domain is required (software development, paint programs, etc), but that there are other domains where "thin" clients are appropriate (email, etc).

The term "rich" versus "thin" really is a misnomer anyways. The complexity of document layout involved in HTML+CSS is absolutely massive, and eclipses the complexity of most "rich" apps by many orders of magnitude. What we're really talking about is "rich clients with a minimal, standardized communication/document spec".

Dennis Forbes
Wednesday, June 16, 2004

I'm kind of glad this is finally happening. 

Here are my views on the fat client thing:

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=143755&ixReplies=47

I've been expecting this to happen since I first used a well administrated Unix/X Windows network.  Most, especially corporate, users have no reason to be administrating their own applications, which is what happens with monolithic desktop apps.

I invested the early part of my career working on experimental thin client systems, only the realize that we already had a good thin client environment in the web.

christopher baus (www.baus.net)
Wednesday, June 16, 2004

I would LOVE to develop most applications as thin clients. For the most part, I don't see any reason why a thin client can't perform most types of application tasks really well.

So I agree with the premise of thin-clients.

But I disagree that the future is HTML. Or anything remotely similar.

It's currently possible to develop responsive user applications--with GUI controls like menus, tree-views, keyboard shortcuts, rich-text controls, and custom widgets--all from within a browser-rendered environment.

It's possible.

But just barely.

And it's insanely difficult.

I've done some of that type of development, using lots of DHTML and JavaScript, and it's difficult and time-consuming. And there's no standardization for how to do it. Everyone who develops a really top-notch application GUI in a browser is essentially reinventing the wheel.

And yet the idea of a remotely-deployed application, with a scripted interface and a load-as-needed application model (with nearly all of the intensive processing on the server), is very very cool.

But HTML is a really clunky vehicle for delivering that type of application.

We need a new type of markup, specifically designed for building thin-client GUI's, delivered over http connections (or better yet, something that's more stateful than http).

That's what I'd like to see.

Benji Smith
Wednesday, June 16, 2004

I think that is what Avalon is supposed to be.

christopher baus (www.baus.net)
Wednesday, June 16, 2004

Programmers want fat native UI apps. Users don't.

fool for python
Thursday, June 17, 2004


It's true that rich client functionality in Web apps is difficult and essentially "reinventing the wheel," but there is hope. So-called "standards-based" Web design and development techniques, based on current and future W3C standards (like CSS for layout), can help us get there, as more of the techniques are becoming best practices and are well supported cross-platform and cross-browser.

I think users do want the _functionality_ of rich client UIs, but only if they're fast and responsive.

A fundamental problem with Web apps is the lack of persistence at the "intra-page" level, for example, while the user is writing a post. There's no easy way to save the current text input, so that if the form submit fouls, the user's carefully typed writing is lost. This is especially bad for content-management-type apps that allow document editing online, but even discussion boards are vulnerable. (Maybe a future browser should have an option to auto-save form field contents so users can't lose work.)

Web apps are still stuck with, for the most part, a string of separate pages tied together, relying on HTTP and cookies to maintain state between actions. Lots of good stuff possible with it, but with difficulty, and so far without everything desktop apps do well.

John
Friday, June 18, 2004

I think Joel and I must use Outlook in a different way from the rest of you, because there is no way web clients are as fast or as useable, even though Outlook is pretty awful in some respects (single-threading and no proper indexing for search).

At work I use Outlook two to four hours every day. I have a folder of messages from job applicants which is 18,000 messages long and growing. I need to do a search for all messages from and to somebody in that folder a couple of times a day.

I have a contact list that is 3,100 entries long and growing. I acces that all the time.

I use the web version when I'm on holiday. It is impossible to do real work over a dial up connection.

I have a database of 3,200 job candidates. There are links in it to their documents - a total of about 700MB (I only keep the documents of possible hires). No way could this be accessed over a PTS. And as for running them from an intranet, why bother. They .mdb and everything else is on a network share and works fine - no need for an added layer of complexity.

Stephen Jones
Wednesday, June 23, 2004

*  Recent Topics

*  Fog Creek Home