Online email providers are continuing to differentiate themselves using rich client technologies. First GMail's AJAX, and now two new online providers are getting into the mix. Earthlink will launch on a Lazslo-based system by June, and startup goowy.com already has an email live beta up and running.

A few weeks ago, startup Goowy.com launched a public beta of it's new online email service based on a Flash front end. Newly launched, Goowy has 4000 members. Goowy chose Flash because of it's multi-platform support and ease of development over DHTML. Goowy also has a very rich UI full goodies such as drag and drop, scroll bars instead of paging, background email checking, and other features usually found on the desktop.

Also, Earthlink, a major US ISP which claims 3.5 million web mail users will launch a new Lazslo-based system in May for it's members. The whole application is a 250K downloadable and also features the expected rich client goodies.

Online email providers will likely continue to adopt rich technologies to stay competitive, which coudl mean that rich client technology will become a frequent software project requirement if online email providers continue to expose average internet users to this new paradigm, especially managers. :)

Online email providers will likely continue to adopt rich technologies to stay competitive, which coudl mean that rich client technology will become a frequent software project requirement if online email providers continue to expose average internet users to this new paradigm, especially managers. :)

Hoo-ray! But don't forgot Oddpost, who were acquired by Yahoo last year.

The first public demo of SmartClient was actually a rich email client, way back in August 2000. It's still on our website, only slightly modified, at smartclient.com.

FYI, SmartClient v5.2 was released earlier this month. You can also download it from smartclient.com.


Jeff Dill
Isomorphic Software
Rich + Thin = Smart (tm)

The first public demo of SmartClient was actually a rich email client, way back in August 2000. It's still on our website, only slightly modified, at smartclient.com

Jeff, your product looks great. Just couple of nitpicks. First, it is great that interfaces resizes when brower window is resized. But scrollbars do not appear on child windows. Apparently, because they are not actually windows.

Thus the second question: why did you try to mimic desktop application? I personally hate windows and the mouse. I tolereate windows only because for now it is the only way to focus application and the user on a certain foreground task, and to limit the drawing area. But what is the point of having child windows in your application? Especially if they cannot be resized or moved? Everything is pretty much flat and static.

Your application looks nice and I am sure it took a lot to make it like this both visually and code-wize. But it does not have real users in mind, those who have paper holder in front of them and churns out 200+ chars per minute. They do not have time for fiddling with mouse. But you do not give them even a chance to use keyboard. Keyboard is non-functional in your application.

Free keyboard! Let people use Tab key! Ditch windows! I guess, enough with May slogans. If someone wonders why bookkeepers or HR personnel or brokers prefer text-mode programs, here you are: simpler and faster input, easy navigation.

Even with child windows, Turbo Pascal and Turbo C for DOS managed to do better. Why? Because everybody was using keyboard at that time.

I am sorry, I was wrong, windows can be dragged in Interactive Analytics (but cannot in Windowed Database Application). Still, I would prefer flat webpage-like interface with better keyboard support. Switching between windows is not evident, current window or button are not highlighted. Tabbing from Office Supply Categories does not highlight Instructions window, I would like it to have colored frame. Tabbing again gets to Find Items, and focuses on the window itself. There is no point to focus on a window, if it has input controls. Also, it is not evident that window is focused on.

In Item Details tab switching is possible only when tabs themselves are focused. This is inconvenient. Also, tabs do not have focus frame on them. And I personally would prefer Shift+Tab instead of Alt+Arrow, but this is personal choice. I suppose that tab order is by row, not by column. But considering number and sizes of fields, I think that by column would be more evident.

But anyway, this is just the rand of keyboard lover, otherwise the applications are really great!

Michael.

Michael -

Thanks very much for your positive comments! It sounds like you have mostly answered your questions from looking at the online examples, just a couple of loose ends:

   1) In that demo application, Windows are just used as a convenient way to minimize and hide UI modules. You're right--this is confusing. If you download the SDK you'll see that this example is provided in fixed-window, moveable-window, and resizeable-pane variants, just to show some of the layout options. We should probably convert the online example to use ListBars (aka Accordions) instead of Windows.

   2) Support for heads-down data entry is a critical shortcoming of most web applications, but not of SmartClient applications. Keyboard navigable, editable grids are the core of fast data entry. Double-click on any record in that demo application to enter grid editing mode.
Arrow keys, tab, esc, enter are all fully functional. Server communication and error reporting are asynchronous, so the operator never has to pause.

   3) SmartClient provides the interfaces for you to implement your own keyboard navigation and focus behaviors (abstracted from browser-specific behavior, of course), but we could make this even easier for switching between tabs and windows. Count on it in an upcoming release.

Please keep in mind that the Test Drive examples are just that--examples. SmartClient provides a very deep GUI stack, with open interfaces at all levels on both client and server. Full documentation is available in the Developer Center and downloadable SDK.

Thanks again, and apologies to other for the extended product plug. :)

Jeff Dill
Isomorphic Software
Rich + Thin = Smart (tm)

In 2000 did you say. Hmm.. It doesn't pay to be to far ahead! Anyway I think the time has come now, great work!

Webstart would be a better option with better marketing and support by Sun.

If you are looking for a webstart based web application framekwork check out jThinRich:

http://grandlogic.com/

For a pure AJAX browser solution you have got to look at echo2:

http://www.nextapp.com/products/echo/

You should try also, wingz framework for Rich Internet Application development.
With wingz and webstart you are able to provide true application on internet.

http://www.zvalley.com/

The browser is almost there.

All we need are javascript threads, so apps can run continuously without being associated with a particular page, and Canvas support for UI rendering, which is in the latest Moz builds I think.

Some sort of javascript JIT would be nice too.

Its then just a small step to MSWord implemented in a browser...

The browser is almost there.All we need are javascript threads, so apps can run continuously without being associated with a particular page, and Canvas support for UI rendering, which is in the latest Moz builds I think.Some sort of javascript JIT would be nice too.Its then just a small step to MSWord implemented in a browser...

Aren't applets a better answer?

All we need are javascript threads, so apps can run continuously without being associated with a particular page, and Canvas support for UI rendering, which is in the latest Moz builds I think.Some sort of javascript JIT would be nice too.Its then just a small step to MSWord implemented in a browser...

I'm afraid all that will open a _huuuuge_ hole for all sorts of abuse, spyware being probably the most innocent.
Why don't use just Java VM instead, with its mature security model? Probably a stripped down version like Micro Edition, just with Swing and java.net classes.

I'm afraid all that will open a _huuuuge_ hole for all sorts of abuse, spyware being probably the most innocent.Why don't use just Java VM instead, with its mature security model? Probably a stripped down version like Micro Edition, just with Swing and java.net classes.

+1

IMO all is necessary:
- make JavaWebStart truly working with Applets to allow precise control over caching;
- have common trusted repository for 3rd party libraries - this will allow Applets to be really tiny;
That will make them start fast!
And JVM of course should be modular and download/upgrade its parts gradually on demand.

... by supporting POP3 and SMTP. That's the service I want to see from e-mail service providers.

The browser might get smarter and smarter, but it's still lightyears behind most dedicated e-mail programs, and it's quite hard to customize a web page as different as Outlook and Mutt are.

/L 'if all you have is a browser, ...'

I wonder when we'll see the first standard based (either W3C or de-facto) tools for Rich Client technology in the Browser. Any "guestimates" out there and what tools would you bet on?

Thx,
J.

I'd rather see the rich client as something that can be pointed too over HTTP if necessary, but would run in its own framework outside and independent of the browser (something like JavaWebStart, but language independent). Then maybe we can restore the brwoser to its rightful place of a hyper-text-markup-language render, and let the RIA-renderer do its job.

Announcement:
"Goowy chose Flash because of it's multi-platform support and ease of ..."

Reality:
"We have detected that you do not have the appropriate version of Macromedia Flash installed. In order to run goowy mail you need to have Macromedia Flash installed on your system. Please click below to download Macromedia Flash and try again. Thank you."

No, Reality:

If you don't already have Flash installed, you are left out!!

Also missing out on a lot of good stuff. More so going forward, with the Adobe takeover of Macromedia!! Its gonna be like the ubiquitous 'Acrobat Reader'.

No, Reality:If you don't already have Flash installed, you are left out!!

Maybe you are left out. But this is because of stupid decisions of others. There are a lot of systems where you cannot install the flash player. Many people do not want to install the flash player.

HTML and CSS (which are freely accessible and useable standards) offer enough power to create a big website. I have seen a lot of websites that use Applets, Javascript, or Flash just to make something like a navigation box where plain HTML (possibly with CSS) would have been sufficient and therefore make the site useless for a lot of people.

It is okay to implement additionol features with such techniques. But a basic usage must be possible without them. Otherwise, you will exclude a lot of people.

I signed up for the goowy service to test it out. OTOH it looks good and has most of the features of a standard mail client (like dnd), but i kept trying to use my mouse wheel over sections that didn't support it, clicking back in the browser brought me to the front page :@

Perhaps an application like that should pop-up without any chrome? Prompts the question, if you can't support normal browser functionality and usage, should you use a browser as the delivery mechanism?

I'm still a fan of browser-delivered applications, and I thought I liked flash applications until trying goowy. Now I can really see the arguement for webstart tho.

Somewhere a long the line I read a comment from a guy saying that by the time we get enough bandwidth to deliver desktop-quality applications over the internet, we might as well start using x-windows again. I thought it was funny at the time, but he might be right...

Somewhere a long the line I read a comment from a guy saying that by the time we get enough bandwidth to deliver desktop-quality applications over the internet, we might as well start using x-windows again. I thought it was funny at the time, but he might be right...

The problem with XWindows is that either you download the full app and run it localy (I wouldn't call it thin), or you run it remotely, which actually makes you app run on the server and export only the diplay to your computer. In this case, having 1000's of simultaneous users would mean 1000 of apps running concurrently on the server, not counting Database, App-server processes and etc. It probably will take your server down.

Regards,
Henrique Steckelberg

Sorry, was being facetious ;)

There is a serious point tho, people know how to use browsers so an application needs to use the normal fucntions or disable them completely. If they are left in place then people *will* click back. The Goowy application shouldn't show the browser chrome, but it does mean that developers need to replicate the effect.

The problem with XWindows is that either you download the full app and run it localy (I wouldn't call it thin),

If such app has only UI logic an calls server for real work then it is thin, think Flash for example.

or you run it remotely, which actually makes you app run on the server and export only the diplay to your computer. In this case, having 1000's of simultaneous users would mean 1000 of apps running concurrently on the server, not counting Database, App-server processes and etc. It probably will take your server down.Regards,Henrique Steckelberg

Same thing happens within Web-frameworks, which simulate statefull client behavior. JSF server side event driven model is exactly what XWindows is all about, but JSF is just more limited. Plus server is busy with endless rendering of pages for clients. This work is delegated to client’s XW-servers and properly coded app server will handle thousands of clients.

Same thing happens within Web-frameworks, which simulate statefull client behavior. JSF server side event driven model is exactly what XWindows is all about, but JSF is just more limited. Plus server is busy with endless rendering of pages for clients. This work is delegated to client’s XW-servers and properly coded app server will handle thousands of clients.

AFAIK, properly coding such app server would involve using shared memory, semaphores, pipes and a bunch of low-level unix APIs, I wouldn't regard them as being easy compared to Java's multithread coding. I am assuming that XWindows does not provide for "server-side" APIs similar to J2EE's, AFAIK it just have APIs for display exporting and event handling, so your JSF x Xwindows comparison, IMO, does not fit.

Regards,
Henrique Steckelberg

AFAIK, properly coding such app server would involve using shared memory, semaphores, pipes and a bunch of low-level unix APIs, I wouldn't regard them as being easy compared to Java's multithread coding. I am assuming that XWindows does not provide for "server-side" APIs similar to J2EE's, AFAIK it just have APIs for display exporting and event handling, so your JSF x Xwindows comparison, IMO, does not fit.Regards,Henrique Steckelberg

Looks like a lot of assumptions without much foundation IMO. What is your stake in JSF Henrique? Just curious.

Looks like a lot of assumptions without much foundation IMO. What is your stake in JSF Henrique? Just curious.

As I have already said before, I coded some XWindows a long time ago, so I am basing on what I remember. I have no stakes in JSF at all, or in any technology for that matter, it is just another tool I'd like to know so I'll be able to use it when appropriate. Plus, I just don't understand when someone comes out of the blue and starts bashing some technology for apparently no reason.

I signed up for the goowy service to test it out. OTOH it looks good and has most of the features of a standard mail client

Not fluid. Does not work for me.

I've been in the RIA world for a while, I have four favorites:

1. For its runtime thunder speed : Jackbe www.jackbe.com
(Cons: lowlevel impl in javascript makes it difficult to maintain and learn, $$$$, no WS consumer)

2. For its incredibly fast speed for development/maintain and easy learn: Macromedia Flex (cons: Its slow, and $$$)

3. For its cost and components available: Bindows (www.bindows.com) and Lazslo.

With the advent of XAML and Avalon, this market perhaps will be short lived. It will be difficult to compete against native calls to the OS (speedy, no pluggins!) and the widespread of Windows in the future (ugh) at least for 'consumer' applications like email clients. In intranet apps, perhaps some of these standards can have a space in this market.

The RIAs (Rich Internet Applications) will be a must in two or three years time since they save bandwith, the development is easier and are much more maintainable since less code is involved.

Sorry guys, the correct Bindows site is www.bindows.net not .com

Most users are familiar with Web browser and rich desktop applications. When they start to expect richer UI from Web application, expectations will not stop on something more then classic Web interface, but less then rich GUI.

I have try Lazslo demo. It looks almost like Windows app, but where are XP look & feel and my Windows theme? There is something strange about response time, right click, cursor shape, alt-tab, alt-f4, etc...

I don’t expect those features from a Web page, but do expect from something that looks like Windows app.

We are in short phase of near rich clients. Prepare yourself for true rich clients, learn some GUI API (like Swing or WinForms), and consider using slightly more JavaScript in meantime.

Nebojša

Using AJAX based approaches for RIA typically means:

(1) developers have to deal with "ugly" Javascript - getting both into problems with runtime errors (non-strong typing in JavaScript) and into into problems with browser compatibililty.

(2) developers have to work with a poor set of tools (...ever debugged a complex DHTML page?)

(3) developers have to write an RIA-component in which they have to carefully design the roundtrip behaviour of this component. A "block-oriented" data-exchange-protocol is inevitable for performance in wide-area-network scenarios.

(4) developer have to carefully distribute logic and data between the front end and the back end.


Casabac GUI Server (http://www.casabac.com) overcomes these problems: developers design the GUI layout as XML definition, using a WYSIWYG editor. HTML and Javascript is generated ("compiled") automatically out of this definition. Developers do not have to know about HTML and JS at all, but can concentrate on the Java-plugging of the UI on the backend side.

A very rich GUI library comes with Casabac GUI Server - covering all aspects of business applications: from field based data input to complex grids to reporting to tree management etc.

...and for all non-friends of RIAs: the GUIs can also be rendered using a stand alone Java client. ;-)


Bjoern Mueller, Casabac Technolgies

Since when did javascript become a 'rich' client. GMail doesnt use anything thats not already part of most browsers.
GMail is thin and rich, Flash is just fat. Which would you rather be?