Opinion: Worries about "rich web applications"

Discussions

News: Opinion: Worries about "rich web applications"

  1. Opinion: Worries about "rich web applications" (55 messages)

    There has been a lot of talk recently regarding rich internet applications, especially with products like Flex and Laszlo. Frank Carver has some worries. He opinines that although the browser isn't perfect, it has become the recent defacto standard. Often in UI design the "pure" best way doesn't win as people have been trained in another. What are your thoughts?

    Excerpt
    All around the web you can now find demonstrations of so-called "rich" web applications written using plug-ins such as Flash or Java, browser scripting such as JavaScript or DHTML, or browser extensions like XUL. What a great many of these seem to have in common is that they start from the assumption that they can ignore or disable all the things I find most usable about the web. Flash applications with no "back" or "undo". Applets that lock up if a resource is unavailable. JavaScript software that pops up sub windows without my control. Long operations with no indication of movement or ability to stop them. No control of window size, fonts, colours, or images. Forms you can't print. No way to copy text or save to disk, text that can't be found by search engines ...

    I know I'm just one quiet voice in a storm, but if you are thinking of developing any kind of "rich" web application, please, please, embrace all the aspects of the web experience we all love so much rather than rejecting them for your own preferences and assumptions. Don't make your application an irritating, restricted and unfamiliar alternative to the web browser experience, make it a comfortable extension to the web browser experience. If you don't allow your customers the control they are used to on the web, you will alienate your users and risk being out-evolved by a more compatible product.

    Worries about "rich web applications"

    Threaded Messages (55)

  2. Different tools for different needs.[ Go to top ]

    If your building an application that does not require screen logic then use pure HTML.

    If you are required to build more complex applications in an environment that either 'does not allow' or 'does not support' plug-ins, then your going to use JavaScript/CSS/DHTML.

    If you need to build applications that are multimedia based, then use Flash.

    "If you don't allow your customers the control they are used to on the web, you will alienate your users and risk being out-evolved by a more compatible product"

    This statement is probably true if you are developing applications for Yahoo that need to apeal to the masses. I develop business application for corporations and my main concern is to provide the product that meets all customer requirements.

    BTW. I always build support into my Flash applications for the Back button.
  3. Users WANT simplicity[ Go to top ]

    I whole-heartedly agree with Tim Bray's take
    here.

    Excerpt:

    "Bzzzzzzzzzzzzzzzt! Wrong. These people have forgotten that all application interfaces (VB, win32, X Windows, Mac OS) used to be “richer environments,” and the users abandoned them by the millions, in favor of the browser, the moment they got a chance (granted, the browser was an advance on previous online-service interfaces).

    I said millions and I meant millions: tens of millions, hundreds of millions of browser downloads from the Netscape that was, and the software vendors fighting the rearguard actions to defend their “richer,” “more responsive,” “higher-performance” client software; and losing, losing."
  4. Users WANT simplicity[ Go to top ]

    These people have forgotten that all application interfaces (VB, win32, X Windows, Mac OS) used to be “richer environments,” and the users abandoned them by the millions, in favor of the browser, the moment they got a chance (granted, the browser was an advance on previous online-service interfaces).
    I did not see people drop their desktop applications. Who has for instance dropped his email-client and has replaced it with a browser-based email-client? Http & Html has brought us new opportunities and let our applications explore new territories. But I doubt if many users will stick to a browser as frontend for their applications if they can go to these new territories on a more confortable manner (with a better UI-experience).
  5. Users WANT simplicity[ Go to top ]

    I think a lot of people have dropped their email clients in favor of webmail, although I don't have data to back me up.

    In my experience, most people I know are using their online hotmail/yahoo/gmail etc for their email. You don't need to know your POP/SMTP addresses, your authentication mechanism, etc. And, your mail is accessible anywhere with web access, not stored locally on your computer.

    So, I'd have to say you picked a bad example =)
  6. Users WANT simplicity[ Go to top ]

    I think a lot of people have dropped their email clients in favor of webmail, although I don't have data to back me up.In my experience, most people I know are using their online hotmail/yahoo/gmail etc for their email. You don't need to know your POP/SMTP addresses, your authentication mechanism, etc.
    Nah. I use web-based mail access just because I cannot get free POP/SMTP for every of my mail addresses ;)
    And, your mail is accessible anywhere with web access, not stored locally on your computer. So, I'd have to say you picked a bad example =)
    This is correct, but what I do regularly (actually, quite irregularly lately), is forwarding all important mail to one address which has POP access, and then downloading it with Outlook Express. Granted, these messages are usually at least one month long, so I just archive them on my laptop. For current activities I prefer webmail because of better mobility.
  7. I must say that this thread raises some fundemental questions and I think it is the most talked about subject in any organization dealing with IT.

    My thoughts on this are :

    a. HTML was meant for sharing information on internet and it along with HTTP was never meant to be used for building applications. If it were to be meant for building applications, HTTP would have built in support for handling state.

    b.I have not seen any HTML based app. as responsive as the rich client.

    c. Now, coming to Diet client, not to introduce another term, but we found it easy to understand. We implemented several applications using applets using the advantages of browser based applications and providing better user interactions like drag & drop, better visual cues and supporting peripheral handling.

    In summary, let us look into the basic problems instead of looking into the wide acceptance. Sometimes, people don't have a choice but to go for pure HTML client with some limited Javascripts.

    If browser is the answer to all problems, MS Word, Excel, Eclipse, etc will be on browser.

    - Madhusudhan
  8. Incidentally I was visiting the LaszloSystems site (www.laszlosystems.com). I downloaded their presentation server and tested their demo's. What I discovered it was amazing. I was surprised by the extraordinary idea of using the XML as a programming language, that is the most abstractive for the machines, OS, language, etc. Unlike XAML, the abstractisation is for WEB and not for operation systems. It remains just WEB and LZX (in fact, no Flash).

    From my experience I felt that the tags bring more reusability than the components (EJB). LZX is a positive example. And productive ( I name this "the possibility of playing in an abstraction level"). All ideas that combine programming (OOP) with XML seems to be interesting. To be seen Digester, or managed beans(from Spring), or tag libraries. Don't you find this combinations extremely interesting?

    It was striking, also, the resemblance of those applications made by Laszlo with the portals (JSR 168). I think that Laszlo brings the maximum productivity. The communication between Flash and server is interesting. This doesn't refresh the whole page, but rendering take place in Flash player. What can it say about the mixture between portlets( JSR 168) and Laszlo? Maybe between a portal server and Laszlo?

    It is clear, loading applications that contain Flash is more difficult. But there is un advantage, once loaded, there are no refreshes due to communication with the server. There is no longer necessary any flow through pages. This idea is clearly shown in Laszlo site.

    Sincerely, I feel that is possible to do many extraordinary things using this technology. Do not let the ignorance to rule your life.

    Cristian Olaru ~ colaru@zappmobile.ro
  9. Although I spend most of my time developing web applications, a part of me still doesn't believe that the browser is the best UI for a server-based applications.

    After all the original design of the browser was to navigate content, not to interact with it in any complex way. Tim Berners-Lee, in his book the Semantic Web, goes on to say he would have wished there would be a way to easily edit the content on the web, but never did he mention the possibility of building web applications on it.

    Now mostly through the usage of the POST HTTP request, we have found ways to build web applications. It is a huge struggle to have to fit into something that wasn't originally design to host applications, and standards are slow at catching up with this limitation (I'm thinking of XForms, JSF, etc...).

    Also most "large" applications require some kind of quick user feedback to be truly useful. In this regard I think that GMail has done an incredible job, but they have taken the position of using a lot of Javascript, at the expense of limiting supported browsers.

    Sun on the other hand is pushing for everybody to use applets, WebStart, JDNC and so forth, to solve the UI interaction problem. I would agree with them if there wasn't the constant problem of platform delivery, which is far from solved despite the new "agreement" between Sun and Microsoft.

    I'm really curious as to how others see the current state of affairs in this regard, as it seems to me that we should be able to provide better UIs to users, maybe through some serious evolution of the browser ?
  10. Javascript interpreters in modern browsers are powerful enough to get the best things from traditional applications GUI. The problem is there isn't enough qualified Web developers to do that.

    Look at Gmail. That's only a minor example what could be done with Javascript. It's one of most underestimated languages in history. It has object model and it's fully prototype-oriented. It's modern enough and can do some great things. You can even write multithreaded GUI using nothing but pure plain Javascript and a simple pool of timers.
  11. Having strong GUI tools like java swing and .NET,
    and HTTP client APIs or even web service/SOAP clients,
    why not let the users download ( or apps automatically check for update) the GUI component rich and robust fat clients.

    Why sun is abandoning JavaWebStart (.jnlp's)? Even microsoft is/was planning for simmilar framework.

    Does really an applet or swing+jnlp need explicit permission
    for port 80 over http or https? Why?
  12. Maybe we shouldn't mix concerns[ Go to top ]

    Everything said about "web experience" is fine... when it comes to browsing web pages, not when working with
    applications. All this rich-client movement tries to bring back all those those things we miss from the client-server time, that is representational and processing control. Very important things for applications. We didn't use to complain about our lack of ability to print a form back then.

    Now, this should be a dialectical kind of thing, and elements from both sides should be incorporated at the appropiate time. Still, it's pretty clear for me that everything mentioned about "web experience" is not as important for real applications.
  13. I am with you[ Go to top ]

    I think it's fair to say that a great majority of computer users know how to use a web browser.
    Um, they know how the link looks like, and they know about Back button.
    Following on from that, it seems reasonable to assume that the conventions of the web browser user interface are the most familiar conventions in software usability. It's easy to spot the impact of web idioms on other software if you look - Microsoft added a "back button" to their desktop file management tools "Windows Explorer" and "My Computer", for example.
    Please, do not forget that browsers were originally intended to browse hyperlinked documents, not to be a thin client. Browsers do this perfectly and everything works in harmony while the browsed resource looks like linked pages. It is an easy concept and users easily embrace it: click on link to open document, click Back to return. But when these linked pages start to represent an application, and obtain input from a user, things change. Now Back button may not work as it was supposed to, now a user can unintentionally resubmit data, can get strange popups telling about something called POSTDATA. The pages can get unavailable or not stored in cache or they would not print or something else. Not all users are familiar with this side of web activity, this is not just browsing back and forth anymore. And it is sad, that instead of writing better code web developers jump to yet another cool technology and claim it to be the silver bullet.
    These are the kind of things that I miss when I use a "desktop" application these days. At least nine times out of ten I just want to read a Word document, so why does Microsoft Word always open it for edit?
    This is simply a stupid Windows (and Mac too?) concept: to associate application with a document. Well, you can view, edit or print the document and you might need different applications for that. But they did not go that far. Use Windows Commander and alike, they allow to assign different apps to different action types. Windows Explorer just sucks.
    And what changes has it made, that it needs to ask me whether to save changes when I exit.
    Probably somewhere in the Normal stylesheet, but you are right, users should not care about that.
    Why do so many "desktop" applications lock up (with no "stop" button) if a resource such as a removable disk is unavailable?
    This was bothering me since I first tried Windows 3.0. They were telling tales about message queue and that Ctrl-C would never get in front of other messages, but this is just BS. Windows allows to process messages (and keys) out of queue, and some applications like Task Manager always filter certain key combinations. I want my Ctrl-C back too.
    Why can't I just stretch a window to see more at once?
    Because fixed-sized dialogs are so easy to design using VB? <Sigh>

    Overall, I am totally with you. I've yet to see rich app which is fast, fully controllable from a browser and adheres to well-known web-design standards. But, even if Flash apps do get better, I am not sure that net should embrace proprietary plugin in favor of standard. W3C committee must sit down and develop and standard for web applications, be it rich apps or not. And should they be based on HTTP, the latter has to be updated too. Hell, HTTP 1.1 is dated by 1999 and talks about what? Right, hypertext documents.
  14. I am with you[ Go to top ]

    At least nine times out of ten I just want to read a Word document, so why does Microsoft Word always open it for edit?
    This is simply a stupid Windows (and Mac too?) concept: to associate application with a document. Well, you can view, edit or print the document and you might need different applications for that. But they did not go that far. Use Windows Commander and alike, they allow to assign different apps to different action types.

    Alternatively, see http://wtonline.vitalnews.com/Pages/Tip0247.html.

    Regards,
    Jens
  15. Where's Vic?[ Go to top ]

    I always look for him to comment on discussions in this area... Early holiday vacation perhaps? ;)

    www.yoavshapira.com / yoavs.blogspot.com
  16. Where's Vic?[ Go to top ]

    Yoav,
    (thanks for all the great work on Tomcat)

    Generals always fight the last war. That is the thing about disruptive technologies. No one sees them coming. The big AM radio stations certainly did not believe in FM radio.

    Certainly in our industry we should be understand disruptive technologies. In ’96, Gopher was bigger than html, html had less than 1% of internet traffic. Then HTML just exploded. Even MS is not fixing it’s browser, what for? Only younger developer that have only known browser UI should be surprised, that’s what will get the bill rates up, not enough supply.
    The web users are quite fickle, as soon as something better shows up, they will switch to that site, so sites need to begin the 6 month conversion now!

    We are “crossing the chasm”. Web apps that go live will be in a crowded market, and my clients believe RiA will get them the eyeballs.

    My resume says I am productive with the new Swing extensions and SoA. (I pluged in Hessian into Tomcat 5.5 just fine for use w/ JDNC).

    I feel like I am saying “Users like Color TV better than B/W TV”, but if you don’t believe in my prediction, than don’t do anything about it.

    .V
    sandrasf.com
  17. I'm developing web applications for the company intranet.
    Most of the time the business unit wants the usability they know from fat clients. But they also want web applications because this is some kind of company strategy. I don't know who invented this strategy but nearly all new applications are web apps, no fat clients anymore.

    With this "rich web applications" demand from the business we developers start more and more discussions about how much javascript and dhtml shall be used.

    I think the HTML and JavaScript standards as from today are not designed for "rich web applications". All efforts to achieve this are a kind of hack around these standards and the intention of web "browsing documents".

    I ask myself: There is a demand all over the world to build "rich web applications" at least in company intranets for business applications. Why was the IT Community and Standards Organizations not able to define a HTML Standard for "rich web applications"? Is it so difficult? Isn't there enough support / demand for such a standard?

    If this standard doesn't come. We will see much more of these cross browser javascript libraries, dhtml tricks to overcome browser bugs (e.g. DropDownList overlaps layer, simulating modal dialogs with onMouse, onBlur events, ...) and other proprietary solutions.
  18. Hammer Syndrom[ Go to top ]

    The notion that the browser is a universal application platform is a case study in mass hammer syndrome hysteria (if the only tool you've got is a hammer, every problem looks like a nail). We flooded IT organizations with developers who had html forms in their toolbelts, and so everything became a web app. Along the way, they re-invented all sorts of stuff that were well understood by the previous generation of mainframe and client-server architects, and repeated almost all the same mistakes. In the end we got an incredibly cumbersome technology not notably better than what it replaced in most areas, and distinctly deficient in many.

    Yes, web apps are great for Amazon and eBay, where the universality of the platform, and the relative predictability of the transactions make overcoming the limitations of the platform worth while. But, they are totally inappropriate for corporate applications that will only ever operate on a LAN or WAN, and where productivity of the user trumps universality of the platform every time. They may be equally inappropriate for applications with wider distribution where interactivity, local statefulness, "richness" or just plain usability outweigh the costs of a rich client distribution mechanism. (God help, for example, the person who suggests that I abandon Quicken on my PC for a web app!)

    In the longer view, we need a client toolset that is not bound by the constraints of either the web paradigm (which notwithstanding the author's love of the back button, is not easy for users to understand, since it assumes a linearity of thought that most people don't exhibit) on the one hand, or of client-server (with its insatiable demand for chatty bandwidth) and the present confusion of alternative rich clients on the other.

    I think this is what Microsoft has realized with their recent push for rich applications, and frankly, I wish them success. Web apps as a univeral paradigm have made my life difficult for too many years already.
  19. Hammer Syndrom[ Go to top ]

    The notion that the browser is a universal application platform is a case study in mass hammer syndrome hysteria (if the only tool you've got is a hammer, every problem looks like a nail). ... Yes, web apps are great for Amazon and eBay, where the universality of the platform, and the relative predictability of the transactions make overcoming the limitations of the platform worth while. But, they are totally inappropriate for corporate applications that will only ever operate on a LAN or WAN, and where productivity of the user trumps universality of the platform every time.
    I would agree with you, if eBay transactions were just plain browsing, but they are not. eBay has problems with Back button in certain part of their app, so eBay would probably benefit from switching to other technology too. I think that I am defending HTML-based web apps simply because I finally got it right, and it is a pity to see that this knowledge will not be needed in a year or two. This development always makes me sad: when finally we know how to do things using tools we have, we switch to different technology and struggle with new obstacles. Anyway, HTML-based web apps are deficient, and something better has to come, but I believe that this New Thing must become a real standard, free and accessible to everyone just like HTML is.
    I think this is what Microsoft has realized with their recent push for rich applications, and frankly, I wish them success. Web apps as a univeral paradigm have made my life difficult for too many years already.
    I am looking at Avalon/XAML development for more than a year and I believe it has a potential to become a New Great Thing. If it provides a real blending of desktop and web, it would be a leap forward.
  20. 2 Different Problems[ Go to top ]

    Mass audience websites and corporate "web" applications are 2 DIFFERENT things requiring their own solutions. There is no 1 solution for both problems, NONE. Public websites should be written in pure HTML (+ any other standards) to reach the greatest audience. Corporate web applications should be written in whatever language fullfills the business requirements. This might be HTML (not likely) or Flash or DHTML or whatever.

    Not a perplexing problem, really.


    Steve Q.
  21. Hammer Syndrome[ Go to top ]

    <blockquoteI would agree with you, if eBay transactions were just plain browsing, but they are not. eBay has problems with Back button in certain part of their app, so eBay would probably benefit from switching to other technology too.
    Yes, sadly this is true. It would be an enormous improvement for those who are forced to write web apps if this one button could be simply and universally disabled for a site. The platform would still carry other serious limitations, but at least application designers would have a chance...

    In reality, the back button is a user interface technology weed: a perfectly legitmate thing in the wrong place, wreaking havoc. In the context of hypertext browsing of static pages, it makes perfect sense. In the context of an application, it must be overloaded with all sorts of freight in a way that the underlying platform never anticipated and can't support.
  22. Back Button & JSF[ Go to top ]

    It would be an enormous improvement for those who are forced to write web apps if this one button could be simply and universally disabled for a site. The platform would still carry other serious limitations, but at least application designers would have a chance...
    Especially the combination of UI-state maintained at the server and the browsers back button is a marriage made in hell. For the brave at heart I suggest to try the back button in JSF-applications. The back button is a wonderfull concept when you're surfing the web. You get it's functionality for free. In case of a web-application the developer gets the button for free, but not having the possibility to disable it he's forced to implement a reasonable functionality for it.
  23. Back Button &amp; JSF[ Go to top ]

    In case of a web-application the developer gets the [Back] button for free, but not having the possibility to disable it he's forced to implement a reasonable functionality for it.
    Marking each page as "no-cache"/"no-store"?
  24. Back Button & JSF[ Go to top ]

    Marking each page as "no-cache"/"no-store"?

    I think this will do as 'PoorMansImplementation'.

    Lets say we have a list and we select item xyz to edit. We edit the item. We return to the list. We delete item xyz from the list. We return to the list. Back, Back, Back, Back ... and we have an error message (not finding xyz) Perfectly logical but I'm afraid that a user will not have the same perception.
  25. Back, Back, Back[ Go to top ]

    Lets say we have a list and we select item xyz to edit. We edit the item. We return to the list. We delete item xyz from the list. We return to the list. Back, Back, Back, Back ... and we have an error message (not finding xyz) Perfectly logical but I'm afraid that a user will not have the same perception.
    If you got an error message like this, then you used one of the better apps. The worse ones just show stale pages and then blow up. But, talking about lists, items and Back, Back, Back, try this (shameless plug follows): http://www.superinterface.com/rdapp/viewList.do Please use MSIE, because Mozilla/Firefox requires page to be marked "no-store" for it not to be retrieved from the cache, and I have not done this patch to my Struts app (shame on me). With the patch the application would work correctly on both MSIE and Mozilla.

    But I agree, that web apps in their current state are hard to develop and something better that can reduce network traffic, eliminate constant repaints and store state info on a client, would be a much better solution. I also hope it will be a standard, not a proprietary plugin.
  26. Back, Back, Back[ Go to top ]

    But, talking about lists, items and Back, Back, Back, try this (shameless plug follows): http://www.superinterface.com/rdapp/viewList.do Please use MSIE, because Mozilla/Firefox requires page to be marked "no-store" for it not to be retrieved from the cache, and I have not done this patch to my Struts app (shame on me). With the patch the application would work correctly on both MSIE and Mozilla.

    Yes, that seems to work, but only by using non-standard HTML, i.e. <head> after <body>, due to a buggy browser, and only in the browsers you've tested, i.e. IE (no pun intended).
  27. hard to argue[ Go to top ]

    Marking each page as "no-cache"/"no-store"?

    This is a perfect example of working around the missuse of the browser an application GUI.
    The same goes for state machines synchronizing the client and server state, catching mouse events with javascript, ...
    The list is endless.

    The thing is it is hard to argue why the browser is the wrong thing for a rich gui application. If you start with "ok, the browser doesn't have this gui control" then someone says "I've a neat dhtml script for this and it's easy". Ok then you talk about the back button, you get an answer of serverstate or worse a trick with manipulating the browser history. Then you have the caching problem and you get http cache control hints. The list is endless. Why do you have to have a lot of workarounds for these problems? Why are there problems at all? Building an applications should be simple. Remember we have to implement business logic, not struggle with a wrong tool.
    It's a hammer, but you don't have a nail here.
  28. ..., even when they are wrong!

    I write a business app using HTML/JavaScript. I have a partial solution to the Back button problem long before I saw the first posting about it on this forum.

    We have to do that if the customer likes the app to be Web-based. Don't you want to sell more?

    From another point of view, do you application really require very high degree of productivity? I'm sure that no customer would require you to write a web-based image editing software. Look at salesforce.com, they are quite successful even though you can do some tasks like logging a customer communication which requires higher/immediate interactivity.

    No, HTML is not the best tool for business app, but it can make to fit most apps. If you can sell more, go with it.
    I think that I am defending HTML-based web apps simply because I finally got it right, and it is a pity to see that this knowledge will not be needed in a year or two. This development always makes me sad: when finally we know how to do things using tools we have, we switch to different technology and struggle with new obstacles.

    That is a good thing! I really hope the market would switch technology once a few years. In fact that's exactly the driving force of this industry. When people start feeling satisfying with their software and don't want to switch, the industry is dead and we all go flip burgers.
  29. Hammer Syndrom[ Go to top ]

    Great post; well said; I totally agree with you except for one small caveat:
    In the longer view, we need a client toolset that is not bound by the constraints of either the web paradigm (which notwithstanding the author's love of the back button, is not easy for users to understand, since it assumes a linearity of thought that most people don't exhibit) on the one hand, or of client-server (with its insatiable demand for chatty bandwidth) and the present confusion of alternative rich clients on the other.

    Shouldn't smart rich clients require *less* bandwidth than HTML apps? Rich clients can hold more local state (without having to mess with cookies), and thus require fewer trips to the server, and/or less data to be sent each time. Plus, rich clients can use a compact binary format like Tuxedo FML, and the information on how to draw the ui doesn't have to be sent to the client each time, just the dynamic data. HTML is very verbose.
  30. Hammer Syndrom[ Go to top ]

    Shouldn't smart rich clients require *less* bandwidth than HTML apps? Rich clients can hold more local state (without having to mess with cookies), and thus require fewer trips to the server, and/or less data to be sent each time. Plus, rich clients can use a compact binary format like Tuxedo FML, and the information on how to draw the ui doesn't have to be sent to the client each time, just the dynamic data. HTML is very verbose.

    Yes, I think they should, and ultimately will. But traditional client-server applications often use very chatty database protocols, or move far too much data from server to client, and take no advantage wait time on the client.

    The sweet spot, in my mind, is neither to hold the entire client on the server, and upload it one page at a time repeatedly (HTML), nor to do all data manipulation in the client and use the server only as a data source (client-server). In the middle is a paradigm where the "right" amount of data is moved to the client efficiently (predictively pre-loading in background threads, where possible), and the "right" amount of state is held on the server, and processing takes place on whichever side is most efficient, considering that in real life neither bandwidth, nor CPU cycles are infinite and free.
  31. Universality of Platform??[ Go to top ]

    Yes, web apps are great for Amazon and eBay, where the universality of the platform ... make overcoming the limitations of the platform worth while. But, they are totally inappropriate for corporate applications that will only ever operate on a LAN or WAN...

    What universality? Every damn web page I go to on the corporate intranet tells me "your browser is not supported, please use IE 5.5 or higher".
  32. Hammer Syndrom[ Go to top ]

    But, they are totally inappropriate for corporate applications that will only ever operate on a LAN or WAN, and where productivity of the user trumps universality of the platform every time. They may be equally inappropriate for applications with wider distribution where interactivity, local statefulness, "richness" or just plain usability outweigh the costs of a rich client distribution mechanism. (God help, for example, the person who suggests that I abandon Quicken on my PC for a web app!)

    Some statement. Well, yeah, this might be true for something like, say the corporate callcenter frontend - even though some of the evil webapp stuff that I saw was still a massive improvement over the mix of "rich" application that they replaced. Anyway.

    The benefit of web apps even in the corporate environment is that they are dead easy to distribute, they require limited computation power on the client (Citrix comes to mind), they are often readily understood - applications for travel expenses, password reset etc. come to mind. Almost any "fat client" application requires an amount of training that is several times as high as the one for web applications. Finally a good web app is fairly easily supported across various OS versions and browsers. It may not work perfectly but it will often work. "Rich" application will often not work at all, require user interaction on administration level (download the new flash version) etc.

    Hopefully, something like XAML will take us a bit further, but there is only so much such a paradigm can do for you.

    Underestimating the power of the ubiquity and relative ease of use of the browser is not the smartest thing. Bill Gates did it too....
  33. I don't think web-apps will ever reach the maturity of full blown desktop applications.
    That said, the new breed of so called "rich web applications" also fall short when compared to real complex desktop applications like Excel, Word, AutoCad, Visio, Eclipse IDE which require a very high level of user interaction.

    There is a difference between tool-apps and web-apps. MFC, VB and Swing are great for writing software tools (Visio, Eclipse IDE), but they are overkill for the not so complex applications which require some form of CRUDES (create, read, update, delete, email, search) functionality. I don't mind trouncing on some theoretical web-page paradigms if the end user/customer likes the look and feel of a "rich web app", although my only concern with these apps would be their scalability and speed compared to native HTML.
  34. It's all true[ Go to top ]

    I agree wholeheartedly with Frank Carver's sentiment.

    Call me old school, but I think a web page should be simple. Tables, images, forms and hyperlinks can be used to represent the vast majority of applications. For those that really require something else -- say, an online game -- I would sooner download a stand-alone application than bear with the atrocities that some people try to embed into or layer on top of the browser. If that sounds ridiculous, think about applications like AOL Instant Messenger, which runs quite effectively as its own program but which has a myriad of difficulties when you try to run it in a browser (I'm not sure if they even support the browser version anymore).

    I personally gave up trying to do anything fancy with HTML years ago and I pity the guys who still have to. I work with some of these folks, and when I happen to look into their code, it is often a nightmareish spaghetti of include files, cut-and-paste jobs, or worse. It seems to me that regular programmers suffered long and hard with UI before we finally developed tools like MFC, AWT and Swing to help us write organized interfaces and now web developers are facing the same problem with little or no insight into how to solve it.

    Frank
  35. It's all true[ Go to top ]

    I've been a big advocate of rich client web applications for years. Remember that's what Java was for originally all those years ago when applets were going to solve everything. If only they worked, we would probably be on "theclientside.com" right now :-).

    But I think I'm finally starting to give up on rich client web applications. Each rich client technology I've researched has so many problems that it just turns out not to be worth it. I think next I may look at Lazlo, but I'm not very confident.

    We've actually tried a different tack with the latest version of our HTML based open source framework (http://www.salmonllc.com/sofia). The thought is that an HTML user interface is "almost" enough for a good user experience for a typical business application. To fill the gaps, we've added some DHTML components to our framework to get us the rest of the way there. Things like drop down calendars and calculators (http://www.salmonllc.com/sofiaExamples/Jsp/example19/Lookup.jsp), tables with scroll bars (http://www.salmonllc.com/sofiaExamples/Jsp/HomePage.jsp) , desktop style row selection (http://www.salmonllc.com/sofiaExamples/Jsp/example6/ProductSearch.jsp), etc... The trick to make it developer friendly is to embed all that ugly cross-browser Javascript in the framework so the web developer doesn't have to know about it. Web developers just telll the framework they want a scrolling table or a drop down box and it figures it all out for you. All the DHTML misery is left to the framework programmer (me unfortunately). It's very new so I don't know how well it will all work out, but so far response from early adopters has been great. And end users seems to really like the extra "cool" factor in their application. We have one customer who originally insisted on all applets for their web app and we've wound up doing most of it with this new DHTML stuff. If we can figure out how to get some drag and drop in there, we shouldn't need applets at all :-).

    Also through this exercise, I've found JavaScript to not be as big a misery to code as it has been in the past. If you focus on the modern browsers (IE 5.5 and 6, Netscape 7 and Mozilla Firefox) getting stuff to work isn't too bad. And I found a few free debuggers that make development go a lot more smoothly.
  36. Browser API[ Go to top ]

    I have not studied to learn how the browser itself is built. Is it possible to expose the base API of the broswer for people to extend in any particular language? Would we not be able in this way to manipulate and extend the page elements into a way closer to, let's say Swing, and not JavaScript? Would we not be able in this way to make components in a page aware of each other without the use of HTTP or DOM? And, on the other hand, why is it so impossible for this JavaScript language to become more developer friendly, with decent debuggers, IDE integrated and so forth? It seems that it gathers a great deal of complaints yet little is done about it.

    Personally, I switch to Swing whenger the browser is not needed.
  37. The Browser - The Plugin[ Go to top ]

    Basically, why not make the browser the very rich client we try to build.
  38. Browser API[ Go to top ]

    why is it so impossible for this JavaScript language to become more developer friendly, with decent debuggers, IDE integrated and so forth? It seems that it gathers a great deal of complaints yet little is done about it.Personally, I switch to Swing whenger the browser is not needed.

    Visual Studio.NET has a good javascript debugger (for IE mainly), and a good debugger is available for FireFox/Mozilla (Venkman)
  39. Keep It Simple, Stupid[ Go to top ]

    Yes, too many clever hackers write too much clever code that adds no real value to a web ap. It's good for the resume but bad for users.

    The simple, declarative style of a vanilla web page means that it can be used in many way not explicitly considered by the author. My pet peeve is the inability to open a link on a new tab/window after some clever hacker has added pointless javascript.

    When Mozilla first came out I thought that it was wonderful that there was no client side scripting. This would keep it consistent, simple, and secure... And now we have ActiveX!
  40. What is interesting to me about this thread is that we are just now at the point where developing public facing web applications is becoming doable again. Gone are the days that you had to support Netscape 4.x. Gone are the issues of having to deal with IE 5.x (forgetaboutit on the Mac). In the past 6 months or so, I’d say I’ve come to a point where I can comfortably tell clients that there are two (Mozilla and IE, alright maybe three, Konqueror/Safari) very strong browsers that their site/app needs to support. To hell with everything else. This has made life for all web application developers a whole lot easier.
  41. Keep It Simple, Stupid[ Go to top ]

    I could agree more. If a framework can "hide/encapsulate/help" provide the well tested DHTML to the end application, then Rich applications can be possible on a browsers.

    And of course I would say that because I have worked on such a open source frame work

    http://www.nextapp.com/echo

    http://echopoint.sourceforge.net

    >>Also through this exercise, I've found JavaScript to not >>be as big a misery to code as it has been in the past. If >>you focus on the modern browsers (IE 5.5 and 6, Netscape 7 >>and Mozilla Firefox) getting stuff to work isn't too bad. >>And I found a few free debuggers that make development go >>a lot more smoothly.

    Dan would you care to elaborate on what free JavaScript debuggers you use and perhaps take this conversation offline to "bbakerman at gmail dot com"
  42. Sorry for the barge-in.....but....[ Go to top ]

    Just wanted to ask if you guys have checked out One$DB, a best-in-class Java database that can be used for free in any environment, commercial and otherwise.
    Not only is the product free, but the company also gives free support on its developer forum.

    Moreover, One$DB blows the competition when it comes to features. Have a look at http://www.daffodildb.com.

    Feel free to send me any comments on uday.parmar@daffodildb.com
  43. Rich Internet Applications[ Go to top ]

    So many wrong assumptions...
    Remember, people did prefer Windows & Mac over VT100-way of using computers because of huge enhancements in the software usability...
    Then the dynamic pages concept grew... Starting FROM: I display in a server-generated page the content of a DB table TO: I'd like to have a real application look & feel only using HTML / DHTML / CSS... :
    First it is impossible to have a 'real' user interaction on a page by page server interaction
    Second we re-transmit over the network an incredible amount of useless data (presentation & client logic) for each page requested (don't tell my about CSS & JS being cached by the client, we still transmit an enormous of redondant-over-navigation-data)
    Third don't tell us HTML pages are 'standardized' so the users know how to use them all, that is uncorrect & using standard Flex components you get a really standard application anyone can understand

    So be confident, RIA is the future, because it unifies Web & Desktop developpement... And Flex is by many aspects the best suited RIA technology available yet...
  44. RE: Wrong Assumptions...[ Go to top ]

    So many wrong assumptions... First it is impossible to have a 'real' user interaction on a page by page server interactionSecond we re-transmit over the network an incredible amount of useless data (presentation &amp; client logic) for each page requested (don't tell my about CSS &amp; JS being cached by the client, we still transmit an enormous of redondant-over-navigation-data)

    If you're serving up a web-based RIA on a page-by-page basis, you're doing it wrong. It's possible to write a javascript app that loads the user interface once, then fetches data asynchronously in the background. No page reloads, the presentation and client logic are only ever requested once, at startup.

    Moving away from the page-based model is, IMHO, the biggest differentiator between rich clients and traditional use of browsers as content viewers. A lot of our server-side tools make assumptions anbout a page-based flow, so there's plenty to re-learn.
  45. RE: Wrong Assumptions...[ Go to top ]

    If you're serving up a web-based RIA on a page-by-page basis, you're doing it wrong. It's possible to write a javascript app that loads the user interface once, then fetches data asynchronously in the background. No page reloads, the presentation and client logic are only ever requested once, at startup.

    Which is to say, you're writing a completely different kind of application - perhaps a rich client application. All we're asking for is tools more appropriate to the job than javascript in a browser.
  46. RE: Wrong Assumptions...[ Go to top ]

    Which is to say, you're writing a completely different kind of application - perhaps a rich client application. All we're asking for is tools more appropriate to the job than javascript in a browser.

    Sure, it is completely different.

    If I were to design a RIA delivery system from scratch, it probably wouldn't look much like a browser with javascript support, but there are a heck of a lot of browsers pre-installed on people's machines. One big appeal of the RIA is not having to install anything, hence there's a demand for javascript-based apps of this kind.
  47. RE: Wrong Assumptions...[ Go to top ]

    Moving away from the page-based model is, IMHO,
    >the biggest differentiator between rich
    >clients and traditional use of browsers as
    >content viewers.

    And what is the major distinction between the two? Is it only on the UI side or is it on the application data model side?
  48. RE: Wrong Assumptions...[ Go to top ]

    >Moving away from the page-based model is, IMHO, >the biggest differentiator between rich >clients and traditional use of browsers as >content viewers.And what is the major distinction between the two? Is it only on the UI side or is it on the application data model side?

    In J2EE's 3-tier model (presentation, business logic, persistence), I'd say it's the presentation tier that's affected. If you're porting an existing app from page-based to RIA, it should be possible to leave the business tier alone.
  49. Not a very powerful opinion[ Go to top ]

    We've developed a lot of rich internet applications in the last year. So this is from the believer's point of view with a lot of relevant experience. How often have you clicked "Back" in Word? The web was designed around a document centric approach enhanced with hyperlinks and simple forms that require a round trip to the server with every interaction. Now, we are deploying applications on the web en masse based on this concept. Guess what? They suck. The web as a universal deployment mechanism for applications requires us to deploy on-line the rich functionality that we know and love from the desktop. This requires enhancements to the original concept of the web. Javascript is one approach, but is limited, requires lots of tricks and is often not cross platform. Flash offers a solid approach because of ubiquity of the player, good tools and platform support and a broad developer community. Yes, basic windows widgets, like undo, all sorts of controls etc, may be important in many of these kinds of applications. If you look at the Flex platform, it offers a lot of plug-and-play widgets with default support for screenreaders. This also indicates that Macromedia is moving in the direction of offering as much windows like default tools as possible. An undo-function, looks like something that could be included in the near future. Check out the Flex widget explorer to get the idea:
    http://flexapps.macromedia.com/flex15/explorer/explorer.mxml

    Kind regards,

    Marc Schipperheyn
    <theFactor.e>
  50. Flash offers a solid approach because of ubiquity of the player, good tools and platform support and a broad developer community. Yes, basic windows widgets, like undo, all sorts of controls etc, may be important in many of these kinds of applications. If you look at the Flex platform, it offers a lot of plug-and-play widgets with default support for screenreaders. This also indicates that Macromedia is moving in the direction of offering as much windows like default tools as possible.
    And you think this is the way to go? Is this a MUCH better solution? Instead of loading pages, we get the whole windowing system, which is far inferior than standard Windows or Mac or Linux windows manager. It is slow, no multitasking, no real drag-and-drop, different LnF, etc. Why on Earth this crippled mini-OS within my real OS is a winner? Flex/Laszlo is just an attempt to draw a UI using plugin which was intended for cartoons. Flash apps provide certain improvement, but they do not blend in with OS, neither visually nor programmatically. The "native LnF", made by drawing Windows-like windows and buttons just makes me sad: why not using REAL windows and buttons? Looking around, I see the only one real improvement, which is Avalon/xaml. Ironically, it comes from the company which is blamed to put the profit before technical superiority.
  51. graphic designers and ooohs aaahs[ Go to top ]

    Flash offers a solid approach because of ubiquity of the player, good tools and platform support and a broad developer community. Yes, basic windows widgets, like undo, all sorts of controls etc, may be important in many of these kinds of applications. If you look at the Flex platform, it offers a lot of plug-and-play widgets with default support for screenreaders. This also indicates that Macromedia is moving in the direction of offering as much windows like default tools as possible.
    And you think this is the way to go? Is this a MUCH better solution? Instead of loading pages, we get the whole windowing system, which is far inferior than standard Windows or Mac or Linux windows manager. It is slow, no multitasking, no real drag-and-drop, different LnF, etc. Why on Earth this crippled mini-OS within my real OS is a winner? Flex/Laszlo is just an attempt to draw a UI using plugin which was intended for cartoons. Flash apps provide certain improvement, but they do not blend in with OS, neither visually nor programmatically. The "native LnF", made by drawing Windows-like windows and buttons just makes me sad: why not using REAL windows and buttons? Looking around, I see the only one real improvement, which is Avalon/xaml. Ironically, it comes from the company which is blamed to put the profit before technical superiority.

    The reason for flash from my bias perspective is graphic artists hate the stock button look and feel. In fact, 99% of the graphic artists I know hate that look and feel passionately. Making UI with flash gives them the ability to create an interface that looks like a painting with a lot of "ooooh aaah" factor.

    it has nothing to do with "what is the most flexible technology." Business managers and sales guys love to have pretty pictures to show clients, so flash is more appealing to them. Of course what the people/users want often has nothing to do with graphic design. It's all about "how rad" my design looks. There's no wow factor in making a website that looks normal and is super easy to navigate and use.

    like it or not, that's reality. of course, you could always fire your graphic/web designer and just use stock widgets.
  52. HTTP is a lousy protocol for most client/server apps doing anything other than browsing. HTML is fine for document markup but is huge step back in terms of writing UIs for writing client apps.

    The 'solutions' which have evolved for writing rich clients inside the browser are essentially hacks to get around these two weaknesses.

    Server side apps have one huge benefit over rich clients from the perspective of anyone developing software: they fix the distribution problem. You deploy your app centrally and all users are immediately able to access the latest version. Furthermore you have control over WHICH version the user is running on (always painful when distribution relied upong users procuring and installing new versions themselves).

    Our original goal when designing Java Web Start (4+ years ago, gak!!) was to give you a way to combine the benefits of centralized distribution with the advantages of real client UIs.

    The idea was to use the browser for what it is good at (finding and launching apps) while retaining control of distribution, and allow stateful clients not dependant on the limitations of HTML (and associated hacks) for application logic or HTTP as the protocol for communication with the server.

    Additionally, an original goal was to enable running those rich clients in 'offline' mode, unfortunately that goal seems to have fallen by the wayside since adds a lot of complexity. It is of course possible to roll this yourself (but that is not exactly simple!!)

    Just my $0.02...
  53. Web app alternatives[ Go to top ]

    I think a well-designed "web app" is one that can be used in a "faceless" browser, a browser that has no interface of its own. In other words, a well-designed web app is entirely self-reliant. As others here have said, the browser's interface interferes, confuses, or is beside the point. But if this criterion is realistic, why use a browser at all? Why settle for HTML representations of Swing components?

    (You can test your web app in a "faceless" browser using Mozilla Chrome by setting up a Windows shortcut with a target like this one for the UNC web site: "C:\Program Files\mozilla.org\Mozilla\mozilla.exe" -chrome http://www.unc.edu)

    But I agree with Alan Cooper, who said that a browser is great for reviewing documents and for downloading applications, and that's all. I feel that facilities for creating applications using HTML pages are a total kludge. I'm sure it was fun designing all that stuff, pushing the envelope on web pages, but the result is a mess: nice exercise, bad product. (We can see the same enthusiastic misdirection of talent in the XML world, distorting XML out of all proportion to its core purpose.)

    At my app shop, people create web apps using a combination of Java, Javascript, HTML, Struts, standard JSPs, other JSP libraries, XML and whatever else I'm forgetting. I write multitier applications with (far more friendly) GUI clients using Java and some XML. Web app maintenance requires knowledge of at least 7 technologies; my app maintenance requires 2. (Well, add Java WebStart to that.)

    Now that Java WebStart is standard and has settled down, we can have all the advantages of web apps in our client-side apps, while keeping quick response, local processing, easy file access, and appropriately rich interfaces. In fact, multi-tier apps with standalone apps for clients *are* web apps, since they operate over the web and have server-side components. But they can operate off-line, when appropriate.

    Experience with customers at our shop shows that they always prefer a client-side app, or a multi-tier app with a rich client, to what is normally called a web app. You should hear the hell that is raised when a real app is replaced with a web app!

    But I'm willing to compromise: I use a client-side app that accepts XML descriptions of real Java interfaces, displays them, lets the user interact, and POSTs the data back to the server from whence the XML came. There are hooks for client-side processing of events and data. Call it an "application browser", rather than a web browser.
  54. I found this great link http://osteele.com/archives/2004/12/serving-clients on java.net, but I could not log in and leave a comment, so I will comment it here.

    I was looking at what Oliver called Model N. (Here is a quick joke: the army general describes the tactical goal and says: "For our purposes let's suppose we have N tanks... No, N is not enough, let's take M tanks") So anyway, the Model N talks about loading XML from the server instead of loading HTML pages. So I thought:

    How is that really different from pulling HTML? In the days of yore we had container (browser), which rendered content (HTML). With Flex/Laszlo we have external container (browser), which holds internal container (Flash runtime), which runs Flash app, which renders XML data. Phew!

    Modern browsers support XML natively. They can load XML, they can find the associated XSLT script from the reference within XML, they can process XML with the XSLT, and they can spruce it with CSS, which can be conveniently referenced from XSLT. My point is, that it might be tempting to use the same XML as Laszlo input data, as well as native browser data. Thus it would be possible to prevent the great divide of web apps for (X)HTML/CSS on one side, and for Flex/Laszlo on the other side.

    Of course, it cannot be this simple. Flash application cannot be replaced by a XSLT script: application can do so much more. Flash app can also use data saved from previous interactions with the server. And here is another idea: to reference existing XML data from recently loaded XML data. Browser can cache XML in the same manner is it caches HTML, so this can be the poor man's client storage.

    Of course, the roundrips would not be eliminated completely and browser will still blink, but at least it might be possible to use the same server-side technology, the same data model and the same DTOs (that is, our XML data) for both Laszlo app and for XML/XSLT/CSS app. Rich apps would just use XML, and thin apps generated by browser, would use XSLT/CSS stylesheets, attached to each XML.
  55. IBM's FacesClient[ Go to top ]

    any thoughts on IBM's FacesClient RIA?

    http://www-106.ibm.com/developerworks/java/library/wa-facescomp1/

    thanks
    hitesh
  56. Yes, the pure best way doesn't win, but right now, when ${mail.web.application} crashes, it takes down ${wordprocessor.web.application}.

    There is no application boundaries between browser instances, and no application life cycle, no interaction model but a non-standardized mess, which is likely to be even more painful in the future.