HTML’s Time is Over. Let’s Move On.

1. Also needing mention is XUL, Mozilla’s Extensible User Interface Language. Mozilla’s UI is built in XUL, as are quite a few applications now (there’s even a nice O’Reilly book).

   cheers,

   Jess

2. David, don’t forget that the majority of “stuff” moving around on the web is basically still text and images. For many IAs, HTML is and appropriate and effective way for organizing and displaying that content.

   “…the time has come to create a new system that is low bandwidth, utilizes a single code base for all platforms, and is componentized enough to make updating and customizations easy using internet-based distribution.”

   Sounds great, let me know when the software industry and human nature allow this for *any* technology segment. Telecom hasn’t done it in a much longer period, even consumer electronics have barely managed to accomodate standardized remote controls.

   Considering that just displaying HTML is a fairly straightforward task, even the browser makers haven’t done too well, as you mention. Who do we entrust with a truly long-range idea like yours? Realisticly, it would have to be Microsoft, given the difficulty of designing, building, marketing, and killing-off of competing standards that would be needed.

3. Paul Ford, over at ftrain.com, happens to have just written a really nice article about considering a geneology of computers which among other things touches on why deterministic technology ideas like “we need a new standard format starting now” don’t work.

4. The URL seems to have gone from that last post. The article on ftrain.com is

   http://www.ftrain.com/archive_ftraintwo_15.html

5. HTML will go away once everyone in the world has a T1 line.

   Flash will go away before HTML. HTML is needed to make .Net, Java, and other server side technologies to work with the client. Even though Macromedia hired Mr. Nielsen, Flash is still over 90% unusable.

6. This is great. I really wanted to provoke a discussion like this, in this community very much so. That being said I want to comment on a few of the comments that have been said thus far (and maybe provoke some more).

   Just to clarify, I am talking about application development. Publishing is still and will still be a great thing to do in HTML. Why the heck not? Especially b/c HTML and XML work so darn well together. As a CMS person I understand that more than most.

   1. Flash – Anyone dismissing Flash out of hand, does not know flash anymore. Flash MX changed all the rules. Also, I did say that it can’t be taken seriously until they improve the development environment so that it performs better for programmers. They may have to split the UI into two. This is something that the folks at Norpath have actually done quite well.

   Sub points on Flash. Flash MX works with JSP, .Net and even ASP appserving environments. It will even run directly from a J2EE environment.

   2. .Net is many things and MS has been doing a wonderful job of confusing people about what it is and promising a lot more. It will have its own UI environment, but that UI environment is just really a marketing scam replacement of VB. It will only run on Windows. The only difference is that it will communicate via .Net protocols.

   3. XUL – The concept is very sound, but from what I was told and from what I’ve seen, it is window dressing only. The content of the applications that it supports still require DHTML to funciton. I’m still stuck using the same limited widgets as before. G-d! I would just kill for one HTML combo-box.

   4. Standards-based HTML – What standards? Who’s standards? What browser? I could write code that is completely standards compliant and I get 2 things: 1. less functionality b/c it doesn’t support as much as the browser say they support. 2. pages that look differently in various browser/platform sets. Standards compliance is a myth for anyone wanting to get more than a publishing environment out of HTML.

   5. Did I say “broadband”? I think I said “bandwidth”. I never meant to imply that broadband should be required. What I was suggesting was that applications that are attempting to be ported to this environment have severe bandwidth issues. Anyone who has worked in a CMS based on the web will realize this once they transfer their first PSD file over a modem so that it can be converted by the server using a digital asset management program, or somone using a DMS that takes care of PPT files and is constantly transferring the documents back and forth for editing.

   What I was really trying to refer to though is the display of large sets of data with much metadata associated with each “row”. The more intelligent you want your navigations to be (actions as well) the more metadata you need to port w/ each row. Thus you need to reduce HTML wherever you can. In our case we can’t use ID tags along w/ class tags and this severly limits our ability to differentiate efficiently styles.

   Ok, I’ll stop there for now … I hope the discussion ensues here. I also want to propose that if there are enough people interested in Web application development that we start our own community. For now the bulk of what we do will continue to be in HTML, but I would like to see other environments spoken about too. Any takers?
   == dave

7. While HTML may, or may not be nearing its end in terms of usefulness, the discussion of Macromedia Flash as an application development tool is lacking in its originality.

   Flash was undoubtedly originally developed as a linear animation tool. However, with the development of Flash MX, and a little outside the box thinking, the possibilities are endless. While Flash works directly with J2EE, .NET and ASP, there are endless other opportunities, including Cold Fusion. As long as you can develop a dynamic content page with any application server, you can pull those variables into Flash, which creates a robust application environment.

   While Flash may be linear in nature, the introduction of extensive action scripting with the manipulation of timelines and content through variables creates an application that is as successful and impressive as the person that developed it….it just takes some talent and a little imagination.

8. flash though is overlooked by so called ‘real’ programmers. the activeX plugin is 500k and the netscape/mozilla plugin is under 700k i think. either way its under a meg and supports so much(video, mp3,xml,etc.). i use flash with PHP. it works well. flash remoting appears to take some steps out however it creates new ones.

9. Michael Woodruff challenged one of my basic assumptions in my article about the user requirements for robustness, so I’ll bite directly on this bone.

   First off, not all applications require the same type of robustness. The technology needs to fit the need in the end. But if we are going to allow companies like SAP, Siebel and my own company to create ported web-based applications of their previous desktop predecessors we need to evaluate the needs at these levels of application development.

   Now that the context is set a bit, where do I get my claim from? Well over the course of the development of my application at Documentum we have over 50 hours of usability tests done. On about 80% of all participants the first thing they requested was “drag-and-drop” both within the application and between the application and their local environment. Why? b/c it is what they do now w/ Windows and MacOS. It is just natural to drag a box around a bunch of objects and then pull them along my screen and drop them some place. The other element they want is right-clicking. Yes, you can right click in HTML, but to do it x-browser/platform is very difficult to implement and test.

   (Don’t ya wish moveable type had threaded commenting instead of linear?)

   — dave

10. Desktop vs. thin-app?

    There was a version of this article that outlined in more detail the history of network based applications: mainframe, client-server (thick-app), web-based (thin-app), peer-to-peer (both thick and thin), etc. … That being said, I have to say that thick-apps don’t solve all of my requirements. While I would love to say that a desktop app is all that is needed, it isn’t.

    Unfortunately b/c of space we couldn’t really delve into the whole Enterprise requirements with application development. DCTM has a desktop app. It is pretty well integrated into the Windows OS. We had to recently build a completely new app for our MacOS users (of course this one only works on OS 9.2 and not OS X.) Neither of these work on Linux. Once more if a customer makes any customizations to their data repository, they need to do complete new installs on their desktops for each of these customization revisions? If they want to do an upgrade they have to upgrade all the individual desktops.

    This solution is not tenable in an environment where finances are ruling all. No one wants the support pains necessary to keep this up.

    Thin-applications (HTML or otherwise) offer a solution to this specific problem that effects non-enterprise and enterprise a like on many levels. How much money does AOL loose w/ every silly upgrade of their product? That is the cost of a thick app.

    — dave

11. Andrei, Flash isn’t for everthing, just like Photoshop isn’t for everything image oriented. I often go back and forth between Photoshop and Fireworks, b/c they both do different things well.

    That being said, I would build Media Player and Outlook in Flash, and not Photoshop. I think Photoshop is not a thin-app. It requires a next level of robustness that requires the full attention of the desktop, while Media Player and Outlook could be argued to be networked based (though MP is less so) and should be thinner and thus in the appropriate environment. Anyone who’s tried to use the webbased version of Outlook knows this to be true.

    But more importantly no one wants to say that Flash is everything. It isn’t. It is better than HTML for most of what HTML is used for, but just like I wouldn’t make Photoshop in HTML, I wouldn’t make it in Flash either. I also wouldn’t make Photoshop in Java either. It needs to run directly on the OS and not through a JIT compiler.

    Someone talked about the footprint of Flash as being too large. Well, it is already on your 90% of most computers.

    Last point … someone said I sounded like an employee of Macromedia. I often wished I was employed as a Macromedia Evengalist or UI Designer, but alas I’m here at wonderful Documentum, and quite happy where I am.

    – Dave

12. Andrei, if you did not know, flash can be exported as a standalone app from the pc to both pc and mac executables. not to mention pocket pc, palmos on the clie, playstation2 etc. also, are you a adobe employee? if you are or are not i really do not care i just want to say SVG SUCKS! why is the w3c picking that over flash for cell phones? the adobe svg plugin for the pc is 2.2mb. the corel svg plugin is even bigger. big corporate money needs to stay out of these decisions.

13. Regarding the usefulness of Flash in creating applications, the term “robust” is certainly dependant on your perspective…would Flash be the correct tool to use to create a new OS, of course not, but in terms of creating an application that, through the use of backend connectivity, can offer the user both a very simple and interactive experience, I think Flash is a great choice.

    Fundamentally, this isn’t about whether Macromedia has created the perfect application and has no room to grow. This is about finding a development environment which currently is a better fit than standard HTML, or Adobe Live Motion for that matter.

14. “here are two companies that could rebuild their products as real desktop apps…Amazon.com and eBay.”

    Good point, although we really ought to stop using these as the only examples ever offered in the IA/usability universe. 🙂 I think a flight-reservation app from Travelocity would be also popular, for example.

    Ebay *does* in fact offer at least two stand-alone desktop apps, I helped usability test one of them. They’re not Buyer-side apps, though, they’re Seller-side. Buyers don’t need a standalone app. The eBay site can handle searching, browsing, and credit card taking just fine. Besides, lots of people will bid on items at home, then again at work the next day, and then check an auction and make a final bid at an internet cafe–a standalone doesn’t help them.

    Many sellers though will put dozens, hundreds, or even thousands of items up for sale, and for that task the site falls down. The ebay seller tools (which have *lots* of third-party competition) speed this up and add tons of features that high-dollar Sellers need.

    I still think that although it’s interesting to speculate about the next application-development environment, that we’re spitting in the wind here.

    You think that companies or programmers or designers will be able to do any better than they’ve already done in terms of developing standard, cross-platform, highly functional tools? Not that I love Flash, but as a software development and marketing achievement it’s about as impressive as you’re likely to see: it runs adequately on several platforms in reasonably predictable ways, provides a reasonably sophisticated programming environment, and lots of people seem to love using it. Let’s not forget that the company that made it is struggling to stay profitable after years of working on this and similar tools, so the market is hardly great. Yet Flash clearly not at the level that David’s proposing we need.

    I really think that if people want a system like David’s proposing, that we’d have to allow Microsoft to do it. No one else has the combination of software dev skill, marketing power, and the legally-sanctioned ability to kill all opposition.

15. I’d d just like to offer up a couple more emerging technologies that are worth considering in this debate.

    Other than saying it SUCKS, I’m surprised no one has mentioned SVG as a potential platform for richer browser-based UIs.

    http://www.w3.org/Graphics/SVG/Overview.html

    Of course it doesn’t compete with Flash right now, because it is only a format, not a development environment (those are still to come). Yet as a format what it does offer is a standards-based, non-proprietary way to publish scalable, interactive user interfaces. SVG enables drag-and drop and many other highly desirable UI features that were previously unavailable within the browser. SVG Plug-in saturation is beginning to rival Flash’s, since Adobe deploys its plug-in with all installations of Acrobat Reader 5. Anyone involved in web application development owes it to themsleves to at least follow SVG’s progress.

    In the shorter term though, its also worth checking out the W3C’s XForms Candidate Recommendation, and some of the evolving implementations of this technology.

    http://www.w3.org/MarkUp/Forms/

    If you are as frustrated as David with the now almost decade-old HTML FORM element, here is the next level. Finally, true separation of form data, logic and presentation, making for far more maintainable forms-based applications.

    Agreed, Flash MX has made great strides. However, one of the main reasons for the proliferation of browser-based applications is that (Javascript quirks aside) they embody a high-degree of vendor independence. Why sacrifice that at Macromedia’s altar (or any other vendor’s for that matter)? I’d prefer to hitch my wagon to a standards body, as we have done until now with HTML.

16. No no no no

    Having worked with plenty of designers over the years I can say that they should stay well away from web site design.

    Rubbish like flash and java and, heaven forbid, activeX generally add zero, zilch, nada nothing to a user’s website experience. In many cases they actively detract from that experience. In some instances I concede they improve access to information, but in the vast majority of cases they obscure it.

    Well used those tools can add to the user’s experience, however in my experience they are always used as tools to make the job more interesting for the agency or to extract more consultancy fees on the site design. I have seen so much money wasted on sites with the latest technologies which then has to be thrown away that I’m astounded anyone has the chutzpah to suggest that what users need is a “richer” experience. They don’t. They need a more valuable one. One in which they aren’t wasting their time on useless doodads and fighting with a designer who thinks they know best how the user wants to navigate through a site. They can get that experience by people spending more time thinking about what information to present and in what order and following simple style rules.

    html is adequate for most needs. It can benefit from eye candy and from better development tools. However the interaction methods it provides are an excellent set, which provide what is necessary while discouraging silly distractions.

    When the design guys get it into their heads that people come onto the internet for information not for entertainment the world will be a much happier place.

    Sorry for the rant but it had to be said

    Brendan

17. Look, anytime you find yourself saying something like “Flash MX doesn’t quite do it, but we should wait for SVG, *then* we’ll have the right thing”, ask yourself: how often do standards bodies achieve something truly “standard”? How often do determinist, top-down, know-it-alls really create something that changes the tide of user & customer preferences?

    This is the same kind of misplaced confidence that the little “social software” movement has right now: we think we know what works and doesn’t with “community”, so let’s just start at square one and “do it the right way.” Even if SVG or whatever comes out and is “better” in some sense than its competitors, we’re still looking at years of varied levels of application support, branching interpretations of the standard by various parties, and ad hoc changes based on fads and politics, just like HTML.

    If you want to fix it, look at manufacturing or engineering: create ISO standards that practicioners and engineers are bound to by law, create liscences and organizations that penalize people and products for failing to meet the standards. Make software builders legally responsible for product quality and compatibility just like the maker of my car, or even my bicycle.

    Let me put it another way: no one will ever solve the technology problem David is describing. Never. And, yes, that *does* mean we shouldn’t try to solve it.

18. SVG: This is not the same as Flash. It is a lot more limited in that you can’t have the same level of text interaction as you can with Flash and talk about an immature technology in terms of developer tools. It is really meant to be a graphic and animation tool, whereas that is what Flash was, and not what it is anymore. SVG does not have form and navigation widgets which are crucial for making an application.

    xForms: This was an incredibly hopeful thing until I took one look at the spec and saw that it still misses the boat on whole section of what UI designers need in their tool kit: new widgets. There are no substantial new widgets to help designers build better interfaces. All I want is a combo box. Can someone please give me a combo box? Is there even a designer on the W3C? The other types of widgets that would be good (sheesh even Norpath thought of this stuff), is a tree control, a datagrid control, and menu control to name just a few. Stated buttons would be nice too. I also need a real modal dialogue screen.

    Again, there are reasons why doing all this in the tag & script (uncompiled) world of HTML will still remain problematic and unscalable.

    xForms is off to a good start, but still misses a big chunk of the boat I’m trying to build.

    — dave

19. Ok, I read it and I’m sold … you should have posted this part … it says it ALL!
    In terms of ROI, the Flash web app has helped

    Yankee Candle by
    *50% reduction in call center traffic.
    *Call center now uses Flash app for their order taking
    *25% increase in volume ordered with the Flash app
    *Reduced order time from a 20 minute phone call to a five minute online experience

    Of course I would speculate that using flash forced them also to redesign their IA and ID models and that these changes alone could have been implemented in DHTML and may have also improved performance … but those #’s are sure satisfying to the eye, aren’t they?
    –dave

20. I think the focus on Flash might be bogging us down a bit. I’d rather like to take this discussion to the direction of …. What are our business & user requirements? What is missing in the current set of technology? Which technologies model some of these traits for the basis of example only? Which technologies also include development environments that allow us to support them?

    Once these questions are answered, we as a community create a manifesto … publish it to everyone and everywhere and begin supporting the new tool sets that start meeting our individual requirements as they become available.

    Every one of the technologies I mentioned in my article are incredibly flawed, but I mention them b/c I feel they make up where HTML is just not even considering to go.

    As I was reading the last comment, my thought turned toward “hybridization”. What would happen in a hybrid of HTML and Flash. Not in the way its been done so far, where Flash is used as a navigation and animation tool, but in a new way. Or maybe in fact Java is better for this than Flash is, except for that MS blunder of breaking it.

    My point is that we have been forced to design in a medium that I feel enough of us agree is not the right one.

    I don’t want to sit here and argue that Flash is better than HTML. I’d rather sit here and figure out w/ everyone why HTML isn’t cutting it and what do we need from companies like MS, Macro, Adobe, et. al. and organizations like the W3C.

    I read the SVG and the xForms specs and I weep. I wonder about all those supposedly smart people who are on these committees and realize it is obvious that they aren’t using UCD methods at all. How can you create a specification of these magnitudes w/o doing field research with developers and users of implemented tools? Who are these people? It is obvious that engineers are the sole contributors to these specfications and it is time that designers were introduced to the lot at least as consultants.

    — dave

21. Wow Andrei, that was impressive … 😉

    Ok, you are trying to tout the OS level desktop apps. I’m all for it if they can do the following (and convince me that they can, and I’m all over it).

    1. distribution: “code once, run everywhere”. No individual installations to maintain. That is what I have in the desktop world right now. If I do an upgrade of my system, I can’t go to every computer around the world in my 50k employee company and do a re-install every time. Customers are refusing to do it.

    2. Configurable & Customizeable – Imagine if I’m using indesign and my customer needs to add a special pallete to their system. How do I apply that customization to everyone’s machine. If I customize in a single central location then I don’t have to deal with individual maintenance.

    3. cross-browser/cross-platform/cross-device (again code once; run everywhere). I can use a single application logic, through separate XSL’s in order to run the same basic application.

    The .Net ? … It ain’t cross-platform unless you say it works across XP, PC, Phone, and Tablet. 😉 … But it can be used on a web-based GUI through many of the technologies I mentioned below.

    Andrei, you think we are headed back to the desktop app? I actually think we are headed back to the mainframe model. Keep as little as possible on the desktop, but give in “infinite” connectivity to many data and logic sources and those should be able to be as separate as possible. For example I worked on a system where the data, the UI and the logics were all supplied by different systems. The data was held on a POS server in a retail store, the UI was supplied by one ASP source, and the OLAP business reporting logic resided on a completely different ASP source (ASP in this case is Application Service Provider; not Active Server Pages) … this is web services. At the time we were designing it on an HTML based system, but today I would LOVE to have it on a richer system like CURL (see I didn’t use flash).
    –dave

22. CURL: Ok, we’ve been paying way too much attention to Flash in this conversation. Curl (curl.com) is very impressive. It has a better IDE than Flash, and it has a set of widgets that are pretty standardized. I really encourage people to take a look at the Siemen’s demo that is on their site. — dave

23. David,

    Thanks for your article, I’m currently working with an organziation that is going through similar user interface growing pains. We have completed the second version of our Transportation/Logistics Web app using HTML, and JSP on the Apache Tomcat application server. Our application works well and allows users to complete their “tasks” per se, however there are new requirements emerging that our current UI architecture will not address. These include drag and drop functionality, power user input screens and offline data entry.

    Extended usability tests have also indicated that the HTML presentation layer working with a Web browser based interface doesn’t ideally facilitate the workflow needed for a complex supply chain management software solution.

    Therefore an HTML presentation layer and UI cannot meet these requirements.

    However, we do continue to need to meet existing requirements of easy distribution, simple customization, configurable from a central resource and cross-browser/cross-device compatibility.

    One of the technologies we have reviewed in detail and are currentlly considering is Altio (http://www.altio.com) I’m actually quite surprised it hasn’t been mentioned in this thread.

    I’m wondering if anyone else monitoring this discussion has researched Altio and whether you have an opinion on it?

    To date, it appears to be one of the most robust web-based rich application development environments out there, is cross platform and offers a fairly small deployment foot print.

    I’d like to sum up by whole-heartedly agreeing with David’s assessment of the movement of Web based applications toward a mainframe like environment. Hey, it’s as simple as noting that this is a requirement of Application Service Provider business plans, and as ASPs gain traction by offering up “rich internet application” functionality, this emerging trend will become more important than ever.

    thx.

24. I just want to respond to some of the comments made about SVG here. (I’ll comment on non-SVG stuff separately).

    First point: SVG *is* intended to be an application environment for the Web. Just as SWF/Flash was designed to be an animation format, SVG was conceived to be something similar. However, along the way we realised (well, we were told by developers) that SVG would be much more useful to build applications than simply draw images.

    And I’m not talking client-only applications here. By building upon XML, SVG becomes a great server-side tool and a perfect fit for Web Services (your application is built in SVG and delivered as XML).

    Have we made it there yet? Not quite, but these things take time, and standards take even longer 🙂

    Second point: One reason why we are taking so long is the huge amount of coordination we have to go through. For example, SVG was designed to be accessible, it’s not something that was tacked on as an afterthought. It was designed to be international, it was designed to be device independant. We’re coordinating with XForms, XML Events and Web Services.

    These things take time and effort. Hopefully though, everyone is the winner in the long run.

    Third: Why did the mobile community choose SVG for its required format (why is it on cell-phones)? Because interoperability is the number one goal in that area, and those guys were not going to let one single company control their destiny. Nokia, Ericsson and co where able to bring their requirements to W3C and build an application platform that they knew would be implemented by anyone.

    Also, Mobile SVG, with animation, has been implemented in under 70K and is now shipping on dozens of mobile phones.

    Not everything is great of course. We don’t have a mature SVG development environment, although Corel and others have made announcements and the future .NET/SVG platform looks promising. I’m not too concerned by the lack of animation tools – I want an IDE (similar to what Macromedia/John said is lacking in Flash).

    Also, other comments here were pretty much on the mark. The Adobe SVG plugin is fairly large (although I don’t think that is too much of an issue really) and the performance of the well-distributed SVG viewers doesn’t rival Flash (although they have a lot more features to support).

    Lastly, you’re right – we don’t have widget controls in SVG.. yet. We’re thinking of adding some in the next release, but as any UI designer will know, this is an amazingly complex task. I’ll also note that AFAIK SWF doesn’t have any UI controls (apart from a button) – they are all generated by the authoring tool (I’m sure Macromedia/John will correct me here if I’m wrong). SVG has a bunch of similar UI libraries.

    Yeesh.. reading this back sounds so much like evangelism it makes me feel ill. Many apologies for that – this wasn’t meant to be a sell-job.

    Before I finish, remember SVG is an open standard still in development. If there’s something you want from it that we’re not addressing, or if you have a reason for thinking it “SUCKS”, then please let me/us know. We are doing it for you guys.

    Dean
    W3C SVG Team Contact

25. Now onto the defense of standards and the W3C in general 🙂

    David, you say that adhering to the standards doesn’t give you the results you want. I think that was definitely true of the old days (read as “terrible days”). It’s even true in some cases today, but it won’t be the case in the future.

    Why? Major browsers are seeing the positives in implementing the standards. Notice that Safari makes a big deal about being standards compliant? I doubt many would think about releasing a browser now that doesn’t adhere.

    Also, the desktop browser has stagnated recently while the mobile browser has leaped ahead. Again, interoperability is
    key to this community. They can’t waste valuable space on bugwards compatible behaviour – standards are all they can expect.

    You complained that the W3C specifications are difficult to read. That’s completely true. They are designed to be read by an engineer who is developing a product. By their nature they have to be detailed, exact and unambigous (which means verbose and confusing to some people). Unfortunately, most web developers are not in the target audience.

    I think that’s a terrible shame, but it’s the way the specifications have to be. We’ve left it up to the companies implementing the tools (such as Dreamweaver, Front Page, etc) to write the end-user documentation.

    Thankfully, there has been a push recently to publish more end-user tutorials and explanations on the W3C website. We’ll see how that goes. Unfortunately you have to remember that we don’t have the marketing/communication budget of any of our member companies.

    I’d love to hear what you, David, and the readers here would like to see from W3C. More tutorials? More examples? An easier way to find stuff on the W3C web site? Simpler specifications? (I’d vote for all four).

    Sorry to sound defensive! I think you’ll find we’re very open to suggestions (and criticism :).

    Dean
    W3C SVG Team Contact

26. This brings to mind the lack of experience design references in web service integrations. Increased efficiencies between middleware and legacy systems don’t necessitate improved immersive user experiences. Development cycles for customization could be compressed. I think negotiating web services in the enterprise should include an ergonomic endgame. Pitch the pitch.

27. [Sorry for the slight OT-ness]

    Vinay,

    “One thing W3C should do on their webpages for specifications is to make it very clear if the specification being read is approved, under consideration or rejected”

    It’s there, but not very clear – I agree.

    Basically, if the title page of the document says:

    – “Recommendation” then it has been given the vote of approval by the W3C Membership. This is as close to “standard” as W3C gets.

    – “Proposed Recommendation” then the W3C Membership is voting at the moment. Normally nothing changes in the text between Proposed Recommendation and Recommendation.

    – “Candidate Recommendation” means it’s stable and ready to implement. A specification doesn’t progress from here to “Proposed” until there are conforming implementations.

    – “Working Draft” means just that. We’re developing something – please let us know what you think.

    – “Note” means a lot of different things. It could be a submission by a W3C Member, it could be the product of a Working Group or it could be an informative document produced by one of the staff. They are NOT approved by the Membership (even though stylistically they may look the same – which is one of the problems we’re trying to fix).

    Hope this helps,
    Dean

28. Several years ago when people first began throwing around the term “DHTML”, I had it drummed into my head (by whom? I wish I could remember) that there was no such thing as Dynamic HTML. This was merely a convenient catchphrase for describing a web page that used JavaScript and/or CSS in addition to plain old HTML. This sort of DHTML was in vogue for a while, and buggy JavaScript eye candy flourished.

    Today, I design interfaces for web applications. I use HTML styled with CSS to present information, but let the server handle the “dynamic” part. I had thought that the DHTML fad was slowly dying in favor of a more semantic approach to web design.

    I agree with this article, that what I remember as “DHTML” is completely unsuitable for a web application. But I disagree that HTML itself has no future. As the language for displaying the interface of a jsp application, for example, it has its uses.

29. First, I want to thank everyone for their appreciations for either or both the article or just bringing up the topic. More importantly I want to thank everyone who has participated so wonderfully in this amazing thread of smart thinking and communal spirit of attempting to both educate all of us on what is currently available, and attempts to work towards solutions.

    I’d like to work with people on sustaining the momentum that was created from this discussion and apply it towards something more. For now, all I can personally offer is the creation of a special e-mail list about web application GUIs. I think that this community of people interested in this topic will include both a more technical and a design aspect of it that will be incredibly useful for uniting the technical with the aesthetic (for lack of a better term).

    Go here to subscribe to the list
    http://lists.htmhell.com/listinfo.cgi/webgui-htmhell.com

30. Adam, first I have to say that this is an incredibly impressive app. I’m very impressed. Is it an ASP? Can I install it on my own server? If so can I customize it? If so are customizations in a ubiquitous envrionment? How well does it scale? I already have X app server licensed can I use it with my existing app server? Can I change its appearance to match my corporate branding? If I do customize it, is there facilities in place for my customizations to be held when I upgrade to your next version?

    Anyway, I think you see my point. For what you created this is a major effort and you should be congratulated. I’m not going to go into the MSIE only thing b/c I can respect that decision, even if I disagree with it.

    My only problem w/ it is still “the blink”, though you go to great lengths to lessen it, it is still there. I think in Flash you could have had a lot better UI and it would have been even better.

    — dave

31. “But the real question Adam poses is: Why do all that for 5% market share in corporate, enterprise apps?”

    Because while 5% is a total installbase, that installbase is spread across the enterprise. Very few enterprises are completely *1* even if that OS is 99% isntallbase. Documentum is an Enterprise software provider who has to make Netscape capable stuff for UNIX and MacOS. Why? b/c our clients demand it even though their own install bases are 1% non-Win32, that 1% has to be dealt with.

    Sometimes we have to decide to not be behavior complete or functionally complete in these other mixed browser/platform environments but enough of our customers require this. If you are REALLY working in the Global 2000 and not the middle tier under that, then you will have to provide more than one browser/platform to sell your products. If you want to stay in the middle tier where these types of decisions can be dictated more easily, or in the workgroup where it is even easier, then you will have no problem.

32. Why web apps? This is not about open standards. I’m sorry but the open source movement, while something I support is not really inherently linked to the need for web-apps or thin-clients. Why?

    First why thin-clients?
    Single source of installation
    Ability to push the GUI along with the data from a centralized location
    Easy customizations, that don’t get ruined when software updates are installed

    Why do a thin-client in a web-app?
    The ubiquity of the browser. Lets face it THE only reason to use a web-browser for an application is b/c of the incorrect belief that we have to put apps in browser to make them easier for people to access. For some reason there was this theory (I know I bought into it) that the browser should be the new desktop. Of course we all know that that revolution didn’t occur, so then all the people who put all this time and energy and technological investment to create this “web-top” had to keep the myth going more and more to substantiate all the original fuss.

    I remember, I was there. That first Internet World where Netscape 4 & IE 4 were battling each other for the better desktop interface. They were even calling it that. I have Layers, I have databinding … blah blah blah. In the end they beat themselves.

    Now don’t get me wrong there are technologies that got their birth from this battler that definitely need to continue, especially XML and its sister XSL.

    But more importantly the real question is why not web-app?

    1. It’s in a web browser, and thus causes a HUGE usability problem. Even spawning a new window doesn’t completely solve the issues.

    2. The # and kinds of widgets available are sub-par. They aren’t good enough. No matter what you do, you are not going to have a resizeable datagrid, a combo-box, etc. etc.

    3. There is no real-time client-side data manipulation. There is this constant need to always go back to the server (I know that databinding through an ActiveX control that comes w/ IE does this, but it is IE only).

    I think that some people have done amazing things w/ DHTML, but it has reached its limit. I also see the current W3C efforts of xForms & SVG as missing the boat. They are in the right direction, but they are distractions from better technologies that given the appropriate energy could really come around and do the job right. Curl probably has the best chance of all the technologies outside of Flash, which has the largest momentum.

    The W3C efforts are noble, but they are flawed in their reliance on the browser.

    — dave

33. Why is desktop connectivity a requirement? In the last message it was implied that this isn’t a real requirement that i”m making it up. Well, I stand by my 30-40 usability tests over the last two years to tell me otherwise. Users working w/ data structured and unstructured are constantly moving that data between the OS and the Server and if the application can’t give them a complete set of tools to do just that then it isn’t doing its job.

    Lets look at a perfect example where something as simple as e-mail is flawed b/c of this lack of support by something that would otherwise be on its way to being a great product, Convea (BTW, Kudos to this team, this product is excellently designed.) Unfortunately its designed on a limited platform (even w/ its IE centricity).

    Try to add a set of attachments? Why can’t a user go to a single folder like their My Documents and add multiple files w/in a single Open dialogue? They can’t? The same is true in Yahoo and Hotmail. Why? b/c the browser doens’t allow for a multi-selectable open dialogue like you get in almost everyother desktop application. It is an expectation that users notice time and time again.

    Here’s a juicy one I discovered today. Why can’t I in Netscape FTP drag a document to the desktop? Something so simple to do. There is no way to drag objects from one medium to the other. I’ve seen users attempt similar operations on countless usability tests.

    If you do not meet the expectations of your users regardless of functional equivalences, you are not meeting the experience needs of your users.

    — dave

34. Hi all –

    I am enjoying this discussion very much, because this has been my focus for a number of years now. I certainly don’t mean this post to sound like an ad, but I would like to invite anyone interested to try out our product, Droplets http://www.droplets.com/developer

    It satisfies most of requirements listed in this forum very well and is in successful production at a number of major enterprises and government agencies.

    Specifically, if I may address the list posted above:

    1. low bandwidth

    Droplets require only roughly 10% the bandwidth required by comparable HTML/JavSCript apps

    2. large variety of prebuilt UI widgets (combo boxes, etc.)

    Dropets features a very large number of pre-built widgets and also has an open API for adding your own custom controls.

    3. interoperable with multiple backend technologies

    Droplets applications are written in standard C++ and Java (with COBOL and VB APIs in the works). Droplets can also connect directly to standard J2EE Servlets. Droplets is a member of the Expert Group for JavaServer Faces and we plan to offer a Droplets Render Kit for JSF.

    4. platform independent

    Yes. The Droplets Server currently runs on Linux, Windows, and Solaris, with an HP/UX version on the way. The Droplets Client is Java and runs on a variety of platforms, in the browser, on the dekstop, and on mobile devices.

    5. ease of distribution (no massive runtime)

    Droplets Client can be delivered as a lightweight Applet (so no need for a client install at all) or as a small desktop runtime.

    6. code lives in a central location

    100% of Droplets application code sits on the server. Very easy to deploy, upgrade, maintain, debug. And it’s totally secure.

    7. interactive manipulation of display

    Complete component-level interaction, just like any standard desktop app.

    8. refresh data without refreshing UI

    Absolutely.

    9. user-controlled access to system services (save, drag’n’drop to desktop, print, etc.)

    Yes.

    10. simple development/IDE

    Droplets does not offer its own IDE, but rather integrates with standard third-party ones, such as Borland JBuilder, IBM Eclipse, Sun ONE Studio, Oracle JDevekloper. An eval copy of Droplets currently ships in the box with JBuilder.

    11. vector and bitmap graphics

    Currently limited, but off to a good start and getting better.

    12. multimedia (audio, video)

    Currently limited, but off to a good start and getting better.

    13. open/unemcumbered by IP

    All APIs for accessing or dealing with Droplets are based on open standards (Java, C++, HTTP, SSL, SMNP, EJB, SOAP, …)

    Thanks much.
    – Philip

35. HT, XHT, U, W, X … there is a whole lovely range of ML’s out there; however the X is here to stay. Too much has been invested. Standards are one thing; multiple standards are another. Clearly the W3C realize things have been getting a little out of hand and have brought in the DI-WG (Device Independence Working Group) to help clean things up. All things considered I think the XML is coming along very well. It’s still early days : your grand children will remind you of that in 40 years time.

36. http://www.macromedia.com/software/central/

37. The service-oriented architectures are on the way. We just built one for the new salesforce.com SOA and it’s interesting. Reminds me of hailstorm, but with a purpose. Here is a link to the “salesforce desktop”:

    http://www.dreamfactory.com/demo/integration.html

38. Has anyone considered or used Tea Trove. It’s available at http://teatrove.sourceforge.net/.

    I was discussing JSP complexity with a friend and he pointed me to this site.

    We both agreed that it looked like it might help separate presentation issues from business logic. I’d love to find out whether anyone here has looked at it.

39. If you’re planning on using Java, check out Canoo’s ULC GUI library for thin rich clients:

    http://www.canoo.com/ulc

    regards,
    sandra

40. Similarly interesting article:

    http://www.orangecoat.com/weblog/pivot/entry.php?id=133

    best line: “many large websites out there still cling to old HTML like pubic lice.”

41. Is it possible you say HTML’s Time is Over???? and, besides, Flash is the solution!!!

    JAAJAJA juejuejuejue jijij.

    DON’T MAKES ME LAUGH, PLEASE

42. Just read this entire article and feedback upon the same, I think you have not used xhtml/HTML Dom/javascript DOM to its fullest. If you use them you will see there are minimum cross browser issues.

    My experience says that presentation layer should always be different than your logical layer… so take any language … i see people talking lot about java here… we can use tiles for layout managment but ultimately your presentation layer will involve HTML.

    XHTML + css2.0 gives you lot of things in the field of accessibility, usability, faster downloads no plugin requirements on your browser….

    you article is 3 years old now… if you have created any site without using HTML/JS/CSS please send me the link .. i would like to see how much future insight your article had…. facts speak louder and clearer… :))

43. Another tool/technology worthy of mention: Rebol

    http://www.rebol.com

    Similar in some ways to Curl, Rebol lacks an IDE, but it has a pretty solid cross-platform, tiny-footprint interpreter. Rebol is useful for batch processing, CGI and development of network-aware thin-clients.

    If they decide to put the needs of mainstream users ahead of eccentric developers and fringe OS zealots, they might emerge as a serious contender.

44. We also can’t ignore the 500 pound gorilla in the room: Microsoft. Their .NET platform is also a way to develop thin client applications (both within IE, with ASP.NET, and on the desktop with small .exe files that connect to servers)

    Microsoft’s version of DHTML and their VB Script languages aren’t a crossplatform solution, but as it stands now, there is already a movement to using Microsoft IE and IIs to deliver internet-based applications.

    …as for HTML. I do not see HTML’s time a ending. Yes, there are a lot of places were HTML just doesn’t scale to (chat is one web app I often see Java used for), but there are many web applications it works very well for.

    Web based e-mail is a good example. While it’s true that Java, Flash or one of the other alternatives mensioned would let us develop more robust interfaces, it would no longer be accessible anywhere (from a laptop running Windows XP, to a PalmPilot with a wireless internet connection.

    HTML is not going away. As andrew points out, most of the web is still just text, and a lot of issues with HTML are solvable (one I see all the time, is large chunks of javascript used to detirmine the browser and then render correctly for it, when the browser could have been detected on the server and then only the appropriate code sent to the client), and all the discussed tools have their own place for one purpose or another.

45. There are too many stones missing in this article to get me across the stream (a metaphor an English professor always chided me with). There are some errant statements in this article also, such as the Netscape 6/7 and IE 6 browser’s vast differences, which we know if one codes to W3C standards will be minimal. The use of JavaScript in the DHTML argument can provide problems as this is where differences lay, not in the HTML/XHTML. While on the XHTML topic the XML Event is on the W3C HTML Working Group plate and may address some of the missing elements discribed in this article.

    The article was missing any reference to why we would need to move beyond HTML as an example. I have worked building Web browser based applications over the past 6 years and have found some limitations, but there are many different desires for applications. I have been part of teams that had dynamic interfaces that allowed the user’s to select data from disparate sources and run analytics on this newly combined data source, then the user could also see the results of the analytics in charts or graphs or Dynamic maps that all ran in a Web browser running DHTML.

    There is some nice functionality that can be gained from DHTML or Flash, but it is no where near driving anybody to making the bold claim in the title of the article.

    One argument was broadband. Broadband for data access? What poor application is being run here. Broadband has its purpose, but using it as a means to create a better interface points to poor interface development for data. Another mis-step was accessability as properly marked-up HTML is one of the best methods of making information accessible and usable.

    Accessing the desktop is the most worry worrisome element. The Web browser is nice because it allows access to information that does not depend on my operating system or requires me to download an application that may have a security hole that provides access to the whole of my information. Being able to download datasets based on a standard allow me to process the data in Quicken, Money, or some other tool that reads the standard data format.

    Groove as an example is a perfect example. Groove made use of XML and browser components to add functionality not available in other applications. Groove is nice and offers functionality few competitors provide. The problem is it does not run on my strongly preferred operating system. Had Groove stayed with a more standards compliant front end to their application rather than closing it to Microsoft only or selected an interface that ran on all operating systems I would still be a devoted user.

    This article could use a serious rewrite to make it half way convincing.

46. “Ultimately, I donÕt see a long term future for HTML as an application development solution. It is a misapplied tool that was never meant to be used for anything other than distributed publishing”

    What about Flash then? It is a misapplied tool that was never meant to be used for anything other than animation. All technologies have (dis)advantages, so we’re always deciding which one is the most appropriate for each particular job.

    Where DHTML or other web/based applications fail, desktop-based software is usually the best solution. It may present cross-platform compatibility problems, but this in many cases is not an issue when a company has already standarized on a particular OS.

47. Of course HTML is still usable for many things, but the point of the article, I thought, was application development, not Web page development. Applications are interactive and do more than call up information; applications let people create things or change things. While I am not immediately going to go out and learn Flash as a result of this article, it seems very valuable to the profession to be looking ahead at what might address the limitations of the current tools. Even if the alternatives are not fully baked, we have to keep testing them until they are ready to come out of the oven.

    It is critical that in future versions, the browser and the contents of the browser not ignore each other. Both the Mac and Windows allow the application developer to leverage the functionality of the OS and the browser needs to offer that same sort of leverage.

    Futhermore, the browser itself needs to be more aware of what operating system it is running under and feed that information to the content layer.

    Which is not to say that browsers should run under only one operating system. Oh, no. If IE has a function that is worth having, then IE itself ought to figure out how it is going to run that function on a different platform, rather than simply say, Sorry, you cannot use this function because I do not like you.

48. I agree with the ‘HTML doesn’t do apps’ sentiment. Not to say it can’t do it, it just isn’t an efficient way to develop stuff. The problem is: Flash isn’t either. I think the main reasons for that are:
    – Flash only recently got a decent programming language
    – the development environment for Flash is based on the animation paradignm (timeline, …) Macromedia should build a developer development environment for Flash if it wants Flash to take the thin app space.

49. I liked the article by the way. Nice overview! Only oversight seemed XUL.

50. “Ultimately, I don’t see a long term future for HTML as an application development solution. It is a misapplied tool that was never meant to be used for anything other than distributed publishing.”

    Few people would argue about the first sentence. Of course HTML isn’t meant to be used as an *application* development solution. That isn’t a very spicy idea.

    The second sentence is more interesting. While *you* might feel that it is a “misapplied tool” I would bet that many of the folks doing the misapplying would not agree. People use tools as they want to use tools. A hammer used as a screwdriver *can* turn screws. (I’ve done this.) People use what you give them. It simply doesn’t matter that some people don’t want other people to bastardize HTML — they do, and they will.

51. The idea that “users are demanding more and more richness” sounds like a Macromedia employee promoting Flash. Who are these users? If anything they are demanding simplicity and easy to understand user interfaces. I guess it really depends on how you define “richness”, but if it adds more complexity from a users point of view, I think you are just adding to the confusion and frustration. I don’t care what the technology is on the front end, it has to be simple and easy to understand on a moments notice.

52. Brendan,

    You’ve done it… I bit.

    There is no point in arguing an obvious point so these links should be required reading for you.

    http://www.boxesandarrows.com/archives/visible_narratives_understanding_visual_organization.php

    http://www.alistapart.com/stories/marsvenus/

    I would say though, that you just haven’t worked with good ‘designers’.

    Good design is ‘fit for purpose’, which may mean not having any ‘graphical’ work involved in the project at all.

    However if the site is essentially brand establishment for example, but with perhaps a requirement for the user to complete a pretty complicated data entry process (requesting marketing data etc) then who does the work?

    Designers don’t JUST do eye candy. Let’s not distance our thoughts of IA/ID/UX et al from those whom we NEED to work with (and in fact some of us actually ARE ;-p ).

53. that last sentence should read…

    “(and in fact WHOM some of us actually ARE ;-p )”

    ;-p

    sh

54. Brendan,

    Let me point you to a few links that you should read lest you make assumptions like these again. 🙂

    You wrote “Rubbish like flash [snip] generally add zero, zilch, nada nothing to a user’s web site experience. In many cases they actively detract from that experience.” In the case of Flash this is just not true. Take for example the recorded increase in online reservations that iHotelier’s OneScreen Hotel reservation system has offered to their clients ( link: http://ihotelier.com/casestudy_broadmoor.html ).

    Then there’s the case of the Yankee Candle Company’s new Flash interface for ordering custom candles. At UIE’s Web App summit this week Harley Manning from Forrester research shared a number of amazing statistics about the ROI of this Flash app in terms of the user and the company (read them here: http://www.flazoom.com/cooler/1043953884,85713,.shtml ).

    The fact of the matter is that HTML is not robust enough to offer the type of interactions that a user expects with application-like tools on the web. HTML is fine for presenting static information, but it falls short in offering the type of interactions that companies need to guild their visitors through complex tasks. As for designers staying out of web site design, I think you need to clarify your position. If you mean interaction designers or UI designers then I feel you are completely off base however I will agree that print designers and fashion designers make for hopeless web design any day.

55. David,
    iHotelier has said this about the ROI of thier OneScreen Hotel reservation interface too:

    “We’ve experienced lower drop-off rates and more successful reservations-the result of the 75% of users who choose OneScreen in favor of the HTML version.”

56. David in your responses you have begun to outline why HTML may not be the best interface for applications. I agree with this. Your article did not make this case other than a poor choice of title that pushed the article beyond was was being said or laid out. I have been building Web based apps over the past few years and agree HTML is not the best interface, but it does work everywhere (including mobile). HTML application interfaces are a huge pain, but doable.

    Flash MX is a great improvement, but there are still some accessilitity problems for Flash (confirmed today at an all day Macromedia training), which will be removed over time. Flash MX is still not ready for the mobile playground as the vector interface makes many interfaces unreadable. One the elements in Flash that is difficult is saving state and printing the interface at random points in an application process. This is something that HTML does easily and many users have become accustom to. Building Flash interfaces that contain state elements (providing the ability to give the user a URL to the exact place in a process to chage information or to read more) takes a lot more work than building the same in HTML. This does begin down the slippery slope of the Kult of Jakob and the blue links with it being standard user expectation.

    Java does have some capabilities that seem to work rather well if building to J2EE. The downside is MS has hosed its usefulness by offering broken JVM. Java has been doing Web Services longer than Microsoft has been able to spell .Net. Apple has a platform for Web services to its users longer than the company creating Mediocre Software (MS) for the masses. The success of applications on Web Services is open APIs, which Amazon, Google, and EBay have proven. The Amazon open API allows a lot of functionality on any platform for any purpose, but it does take initiative to make it come off.

57. Mixing Flash and HTML is a good idea for somethings as there are many folks that do this already. This mixure is good for making drag and drop components that sit in an HTML page or that can provide a feed back window. The downside is if you need to have an accessible application there is not currently a way to get the focus out of the Flash components when the user is not using a mouse.

    The other problem for everybody is saving state and printing the HTML and Flash page. I talked with Jeremy Allaire about this yesterday, who stated it is possible to print and save state in a Flash only page, but it takes a lot of work to save state (useful for linking to). When the Flash is mixed in an HTML page there is no way to print and no way to save state, similar to Java apps lodged in an HTML page. The HTML page uses what is seeable in its API to print. In a sense what the object in the page does is add a second API and this second API is a hole in the original API is does not print, nor is it included in state.

58. I just did a cursory evaluation of some Rich Interface options for our product, and I’d instantly rejected Curl. The plugin was too heavy and none of the applications worked too well on my end.

    One technology I found interesting was Vultus Webface ( http://www.vultus.com )

    However in my opinion technology should not be a consideration. Especially, with the advent of web services (and no .NET is not the only platform) we have a whole new way of looking at web applications. One promising proposal for an UI standard is WSUI, but it remains to be seen if it will find momentum (even in the web services community)

    But I don’t think it is the end of HTML, YET. It would still be the most prominent interface delivery platform, but we will shortly start seeing more hybrid interfaces. And it would stay that way for a long time to come…

    Nav

59. I took a look at CUrl this week when they were at UIE’s Web App summit. Their product looks good but I can’t see it being deployed 1) on the web or 2) as an interface for consumers. Curl’s real market is enterprise applications where the sophistication of the product really makes sense.

    The idea of creating desktop applications that the user downloads is not going to be widely accepted. Users are leary of any downloads on the web, even from trusted sources. The fear of downloading a virus or worse, crashing their computer, make this option not feasable for most B2C solutions.

60. Have to throw my 2 cents into this.

    A the person partially responsible for Flash (actually it’s ‘fatter’ predecessor Director/Shockwave) I gotta say that you’re right on in this essay.

    Based upon the feedback you’ve gotten this is a rich area for discussion. My own feelings are in line with where you’re coming from – that ON-LINE, web based apps are where we’re going – not more desktop based .exe’s.

    There’s allot more ot Flash than just sexy animations – but that’s obvious. I noticed no one has mentioned Bill Appleton’s Dreamfactory platform?

    – Marc Canter

61. Hmm. Perhaps it’s time for me to revive CocoTalk, the online application framework I built to run with COCONET, a client/server environment for running online services. Built before the rise of the web, from 1987-1995, it was a way for people to build server-based apps whose UI and content was local to the user’s platform. Which meant from a user perspective, it felt like a local application. I’ve always felt that HTML was ill-suited as an application architecture, as was DHTML. I’m glad to see others are discussing this issue.

62. Hey, Andrei, are you writing all this stuff on the clock…? 😉

    David, good overview, thanks. I agree with you that we need to make SWF production more approachable for straight programmers… the animation can be ignored, but for advanced newcomers it can get in the way too. We haven’t implemented an IDE yet.

    The article’s title is effective, but I still believe that HTML/JS can be useful for many web applications… I see a continuum of deployment paths, each with its own strengths and weaknesses:

    HTML/JS web applications:
    * + text-oriented
    * + clientside logic can be fast
    * – new data from server requires resending UI & logic
    * + multiple proprietary implementations
    * – multiple proprietary implementations (!)
    * + supports promiscuity: visit any site you want and you’re in a safe sandbox

    Component-in-browser web apps (Flash, Java eg):
    * + can be deployed across multiple browsers, OS, etc
    * + UI & logic can be retained during data-refresh
    * – usually must be online to use
    * + supports promsicuity (Flash has own sandbox)

    Standalone apps:
    * + can work offline
    * + can be trusted with personal data
    * – you must trust the native code you execute; no promiscuity
    * – development costs increase for multiple environments
    * – installation costs are higher

    This is a quick plus-and-minus chart, but shows how the needs of the audience greatly influence the choice of deployment strategies. I’ve got a little more in an article, but this also compares Director to Flash and doesn’t directly address this “paths of deployment” idea.

    Anyway, thanks for the article, I know that other Macromedians have already printed out and studied your conclusions and the replies. There’s a lot more work to do here still….. 😉

63. oops, URL didn’t take… more here:
    http://www.macromedia.com/desdev/jd_forum/jd021.html

    About “Should it all happen on the server?”, then I don’t think so, at least not in many cases:

    Server-side control:
    * + can use your customized services from various machines
    * – privacy/security concerns
    * – can’t use offline
    * + can aggregate and cache requests from many customers (think of RSS pulls, eg)

    Client-side control:
    * + can use stored data offline
    * + you keep your prefs locally & retain control
    * – if you switch computers or to your PDA you’re hosed
    * – if calling multiple web services you’ve got more latency than if your server aggregates, caches, and segregates it for you

    I think we’re going to have to tune the balance between server and client for each application, each specific set of user needs — even that single question of “Do I prefer to work offline or do I prefer to work from any computer?” is a hard question to answer universally.

    jd

64. David Heller wrote about xul “The content of the applications that it supports still require DHTML to funciton”. This is completely wrong. XUL means Extensible User Interface Language and it’s based on XML, JavaScript and CSS. XUL is a perfect solution for designing user interface, the only problem is that it comes from Mozilla that it’s not so strong than IE. I wished that XUL arrived from MS, in this case all our problems would be resolved. With Mozilla/XUL you can make remoting, connecting to a database and you have *all* widgets you are used to use in traditional desktop programming languages.
    There are also real project to use XUL with Java, read the Chronicle of the Xul Revolution:
    http://luxor-xul.sourceforge.net/post/
    For more information about xul take a look to:http://www.xulplanet.com/

65. >But linear timeline-based development just doesnÕt make sense in an application environment.

    This isn’t fair to Flash. There is absolutely *no* case in which you must code an actionscript that uses more than one frame. That you are able to do so is an added bonus (unless you don’t know AS in wich case this sentence would seem a bit odd). You truly can do everything through Actionscript now, from creating classes of shapes to naming and moving them around.

66. Probably the most broken article on technology I’ve ever read. I think I can even hear the Macromedia and Sun engineers gigling in their office bathrooms. Let’s construct an alternate universe with no HTML in it. Only Flash, Java and Curl. This means that for the world wide web to be successful every person involved would have to be an usability engineer. Flash, Java and Curl would give birth to very treacherous and non-obvious interfaces made by people who think they’re creative, just because they can. You’ll have to spend a lot of time looking for a form like thing and would be surprised to find that the form is animated and slides out from within an image. The world wide web would certainly fail badly in such an alternate universe.
    I wonder what David Heller proposes for this very web page filled of comments.

67. Heck, forget the fact that the authoring tools are ridiculously expensive and poorly designed themselves (Macromedia can’t do interfaces, period), let’s remember what makes the web great:

    Text.

    Yep, text. Good old ASCII. If it weren’t for the wonderful things you can do with text, the web would be totally useless, a mere curio for the nerds, the kind of nerds that may have bought kit computers back in the 70’s (were they alive/sentient at that time).

    Flash is the anti-text. You can’t search it, index it, copy and paste it, or change its font size. You can’t view it in Netscape 1.0. You can’t view it in lynx. You sure as hell can’t “view” it with a screenreader. How many Flash web sites have you REALLY used? Or, not to put too fine a point on it… how many Flash sites have you tried to use when you were trying to find CONTENT? Done much research using totally Flash-based sites lately? Yeah, that’s what I thought.

    I like Flash as much as the next webtron, when it’s not in the hands of EVIL (or merely misguided) people — which sadly turns out to be, as Vinay Pawar so eloquently points out, most people.

    But it’s no HTML replacement.

68. Oh, and let’s not forget the very serious potential dangers of trusting all our webby eggs to the basket of one corporation.

69. Sorry that I’m pursuing the off-topic here, but some memes need nipping…. 😉

    “But it’s not HTML replacement.” True, but a straw man. Hypertext Markup Language remains valuable for documents, same as always. It can also be buttressed by styling, some rich-media, and clientside logic. But as David pointed out, it doesn’t scale well for web-based applications, and other tools may be more appropriate for this different task.

    “Can’t search, copy or paste.” Can too. Textfields can be copied at author’s discretion. Search engines have long pointed to SWFs, and some such as Atomz indexed into text and links on their own, and now more engines are using the SWF Search Engine SDK to easily index within a SWF. This argument would be more appropriate against using JPGs on the web, save that most people would reject this as silly a priori.

    “Can’t change font size.” Guilty as charged. You can zoom in on the entire piece, regardless of browser, but there’s no CMD+ for text as in Mozilla.

    “Let’s remember what makes the web great: Text.” Could I amend that to “Great text makes the web great”? Thanks, I needed that…. 😉

    Regards,
    John Dowdell
    Macromedia Support

70. David,

    HTML is the ultimate in “open source” as a non programmer, non developer I can copy off other peoples code. I can click on “view source”, and get it, both cognitivly and in the cut and paste sense. That is why the web erupted in the way it did. Can any of the other options you mention match that?

    Walter

71. John,

    I stand corrected with regards to the ability of Flash to be relatively OK for text, but I’m not changing my overall stance that Flash is a very bad way to go for web pages. Whether or not it’s an option, you’ll find that some 90% of the web pages that use Flash as the sole interface don’t let you touch the text. Zooming in is obfuscated, practically a hidden feature, and results not in more legible text but very fuzzy pixelated fixed-width text — just blown up. That’s not a solution to the problem and it certainly doesn’t solve the accessibility or backwards compatible issues. Even the most sophisticated of xHTML/CSS/DHTML-based sites can be made to scale with relative elegance for old or special case browsers.

    You haven’t addressed my other concerns, and no doubt Macromedia has no intention of doing so.

72. Has anyone here actually *tried* Vultus (http://www.vultus.com) or Altio (http://www.altio.com)?

    Vultus appears to be MSIE/Win only (other versions are ‘in development’), so I can’t see it. Besides, it appears to just be a pre-built JS library, so while it will undoubtedly shorten development time it won’t cure any of the ills currenlty suffered by (X)HTML/CSS/DOM/ECMAScript.

    Altio is based on a Java applet, so all the usual caveats there apply.

    After reading the article and the discussion, it appears that the requirements for a solution are as follows:

    1. low bandwidth
    2. large variety of prebuilt UI widgets (combo boxes, etc.)
    3. interoperable with multiple backend technologies
    4. platform independent
    5. ease of distribution (no massive runtime)
    6. code lives in a central location
    7. interactive manipulation of display
    8. refresh data without refreshing UI
    9. user-controlled access to system services (save, drag’n’drop to desktop, print, etc.)
    10. simple development/IDE
    11. vector and bitmap graphics
    12. multimedia (audio, video)
    13. open/unemcumbered by IP

    11-13 are probably optional, but recommended.

    The mooted solutions so far:

    SVG + XForms
    — lack adequate widges
    — lack adequate interactivity
    — currently no support
    — no IDE

    Java
    — complex development
    — problematic distribution (multiple JVMs)
    — no vector graphics (?)

    Curl
    — not platform-independant
    — encumbered by IP

    Flash
    — limited prebuilt widgets
    — limited access to system services
    — awkward IDE
    — encumbered by IP

    Vultus
    — platform dependant (for now, at least)
    — limited set of widgets
    — limited interaction with display
    — limited access to system services
    — encumbered by IP

    Altio
    — complex development
    — problematic distribution (multiple JVMs)
    — no vector graphics (?)
    — encumbered by IP

    XUL
    — no IDE
    — difficult distribution (need Mozilla)
    — no vector graphics

    Rebol
    — ?

    What else is there? What have I missed?

    I think a technology that meets all the requirements above would have an incredibly democratizing effect on app development, just as HTML had an incredibly democratizing effect on publishing.

    Such democratizing would produce a heckuva lot of truly awful apps, but it would produce some tremendous innovation. That’s an exciting thought.

73. Hi Amy, I’m not sure that I’d want to try to convince you of anything… as David mentions in his original article and comments, the goal is to discover which technology can be suit the current needs of the current site’s audience — to get a good fit between problem and solution.

    (A secondary goal, unique to tool producers, is to find how the current technology can be improved to better match developers’ needs for their audiences.)

    For Flash, if you’re seeing fuzziness with enlarged text, then I’d suspect you’re looking at a site where the developer chose to use bitmapped text, rather than the usual curve-based text. If by “accessibility” you’re seeking to provide an audio representation to visitors with low visual acuity, then check into the audio-hinting mechanisms in Flash… very useful stuff.

    I’d often agree with you that a graphically-savvy interaction format like SWF would not always be the first choice for a web “page”… if the content would conform to presentation in a “page” metaphor, then it would not always require the levels of interaction we’re speaking about here.

    jd/mm

74. Chris–
    Looking at your list, REBOL stacks up pretty well.

    REBOL/View:
    — Platform independent (see http://www.rebol.com/view-platforms.html )
    — Small runtime (400 KB for GUI version, includes over a dozen network protocols)
    — Simple language designed specifically for scripting networked thin clients
    — No visual IDE (use your code editor of choice)
    — No vector graphics
    — No browser plug-in (doesn’t work in browsers)
    — Limited pre-built widgets
    — No anti-aliased text

    What are the challenges for REBOL? For one thing, it’s not very well known, and it’s not owned/backed by a giant corporation. The company has a slighly confusing product line (/Core, /View, /Command, IOS, SDK, etc.). Also, most developers are used to curly-braced languages, and don’t take quickly to new syntaxes, no matter how simple or well designed (a link on the REBOL.com page shows what you can do with one line of code).

    See http://www.rebol.com/pre-view.html for some samples of REBOL apps. The default widgets do not conform to well-established desktop GUIs, but I expect that REBOL will undergo a metamorphasis in the near future.

    I have a list of approx. 20 companies/technologies in the rich client (beyond the browser, X-Internet, etc.) space, I’ll post a link to that list when I get a chance.

    Best,
    Ed

75. The presence of Dean Jackson from W3C is reassuring here. Alice in Wonderland.
    Some fairy tale creatures would not want to provide a standards validation feature built into their authoring tools. I like the Checky addon for Mozilla.
    Can someone please elaborate on what “scalable web-applications” really means.
    One thing W3C should do on their webpages for specifications is to make it very clear if the specification being read is approved, under consideration or rejected.

76. Regarding XUL, a member of a list where I posted this article pointed me to a lightweight XUL implementation in Java that supposedly works with either the Sun or MS JVM:

    http://www.mycgiserver.com/~thinlet/overview.html

    Does this address concerns with either environment?

    More XUL links:

    http://luxor-xul.sourceforge.net/post/links.html

77. Development environment for Flash: http://www.laszlosystems.com/

    Looks like it provides a more typical development environment (no timeline) and abstracts the development from the display technology so, for example, the final output could easily be switched to SVG or XUL if either of those technologies become widespread.

    Interesting or no?

78. Ed,

    On a mailing list where I posted this article, someone else mentioned Rebol but noted that it was expensive to distribute.

    Unfortunately, I can’t view the demos as there’s no Rebol View for OS X (or Mac Classic, for that matter). Kinda throws a wrench in the ‘platform independant’ bit, doesn’t it?

79. Hi Chris–
    With regard to REBOL, there are some issues that they need to work out.

    My understanding is that REBOL/Core and REBOL/View are free for non-commercial use, but they require licensing for commercial distribution (see the SDK product). I suppose if they made this technology free, they would need to make their money somewhere else, perhaps by selling a visual IDE.

    IIRC REBOL came into the world during a period when Mac OS 9 was on the way out, yet OS X hadn’t fully hardened. I notice that REBOL for OS X was announced (see the home page). The founder and lead architect of REBOL is a former Apple employee, so there is credibility there.

    Apart from the Mac, REBOL also lacks PalmOS, Novell, and maybe one or two other small-cap platforms. Someone earlier in this thread correctly pointed out that platform independence can result in the loss of important OS services, and in my opinion that is a greater danger than not supporting every imaginable OS.

    HTML is certainly not going away for the forseeable future– as Paul Graham wrote, HTML is “good enough” for most needs. I do see the need for interactive tools. I was organizing my Wish List at Amazon over the weekend, and due to the repeated browser refresh, it was really tedious.

    — Ed

80. for one simple reason…html will not go away anytime soon…the people have been empowered and they are embracing it…the people want to publish…

    only when the tools become so simplified (like html) will things change…i see signs of this with Flash MX (and i’m not talking about the animation aspects of it)…but i’m not an expert code person, so my knowledge is limited…

    the people want to publish…let them…or make tools for THEM that will allow them to participate…

81. I answer to the Chris Kaminski 13 points from a XUL perspective.

    1. low bandwidth

    With XUL you can follow two ways. The first is the same we are used to do, transfer all html to the browser. In this case you transfer XUL, JS and CSS. The second way is with remoting, and you transfer only the data from the server to the client and vice-versa.

    2. large variety of prebuilt UI widgets (combo boxes, etc.)

    XUL have almost all widgets. You can customize them using simple CSS or the GUI inherit the browser theme.

    3. interoperable with multiple backend technologies

    Ok, server and client are separated. The same XUL client can works with ColdFusion, PHP etc.

    4. platform independent

    Mozilla/XUL works on Win, Linux, Mac.

    5. ease of distribution (no massive runtime)

    This is a problem, for using XUL you need mozilla. They are working to a run-time separated from the browser, but it will be always some megas.

    6. code lives in a central location
    Yes. Code can lives in the server or shared with the client.

    7. interactive manipulation of display
    Widgets interaction are made usign Javascript. I heard rumors about using Pyhton as a scripting language, but I think it will not be implemented very soon.

    8. refresh data without refreshing UI
    Sure. Get data with XMLHTTPRequest(), SOAP API, or using appropriate widgets that have a datasouce attribute and automatically download and display the retrived data.

    9. user-controlled access to system services (save, drag’n’drop to desktop, print, etc.)
    Yes, with Mozilla/XUL you can develop two type of applications: installed and not installed. If you install the application then you can have access to all system resource. This part of Mozilla is very similar to Java Web Start. You can install an application and every time it is started you can check for a newer version and silently download it.

    10. simple development/IDE
    HomeSite is a perfect candidate to write xul code, but unfortunately there is no visual IDE.
    Anyway, someone started to develop an XUL IDE using XUL:
    http://xulmaker.mozdev.org/

    11. vector and bitmap graphics
    I don’t know, maybe with SVG.

    12. multimedia (audio, video)
    You have the same possibilities that have Mozilla.

    13. open/unemcumbered by IP
    ?

82. vaska–

    The issue isn’t publishing. HTML is fine for that (well, maybe not ‘fine,’ but certainly ‘useful’).

    It is in the context of developing richer interfaces than vanilla (or even chocolate raspberry truffle) hypertext can provide that HTML falls down. Not surprising, really, as it has already well exceeded its original mission without such additional burdens.

    I agree that Flash won’t replace HTML anytime soon for garden-variety publishing. Based on their comments here, I think the MM folks agree too.

83. Point:
    HTML is less than ideal for applications

    Counterpoint:
    HTML apps are really cheap to build (as long as you forget rich interaction)

    There is a very narrow market which is willing to develop ‘Flash-plications’. Most large companies gravitate towards Web apps cause they are so easy to build and maintain. Those looking for a “Rich interface” are absolutely exploring .NET Winforms, Java Flash Remoting with Web Services, standalone VB apps, etc… In the apps game, Flash is just another player.

    I would say that the demand for rich client apps over the net is probably almost zero- therefore the technology is not the issue. Compare this to , say, the demand for Flash gaming.

    Everyone wants games on the web. Flash is definitely NOT the best tool for the task, but it wins cause it meets the needs AND IS CHEAP.

    PS- This is a great site with some great opinions!

84. suman–

    Not too many people asked for the web itself in 1990, either. That doesn’t mean they didn’t want it, just that they didn’t know what to ask for.

    Yes, they do want to get their task accomplished in the shortest possible time. In some instances, rich UIs are the way to do that:

    1. Say you want to delete a dozen junk mails from a webmail client. There are another dozen-odd messages you want to keep. Which is faster: clicking a small checkbox next to each of the messages you want to delete, clicking the delete button and waiting for the page to refresh or drag-selecting/shift + clicking the whole list of messages you wish to delete and dragging them to the trash can?

    2. If I want to edit my Amazon wish list, is it faster to scroll through the list selecting items to delete, click the delete button and wait, or to select the item and hit the delete key (or drag it to the trash)?

    3. If I want to watch a few auctions on eBay, is it quicker to drag the auction title to a ‘watched’ pane on the page or to click the title, click the ‘watch’ button, wait for the page to refresh then backtrack to the search results?

    I get the distinct impression that those arguing against rich UIs are reacting solely to the same shortcomings of current technologies that David points out in the article.

    Really, folks, nobody here is advocating that /The New York Times/ rebuild its site in Flash, and AFAICT it’s the very fact that rich UIs on the web *are* currently subpar that inspired the article.

85. >>Yes, they do want to get their task accomplished in the shortest possible time. In some instances, rich UIs are the way to do that

    You are absolutely correct! The problem is, most of the time, the *users* aren’t the ones who are *paying* for the application!

    Web apps exist because they easily and cheaply reach a vast audience with minimal concern for disparate platforms, widget sets, and ytes, plug-in availability.

    I see an opportunity for rich apps in limited-use situations, where the user base and their needs are extremely well-known. But for apps used by the public, like the DMV, or a major university, rich UI is just adds another layer of complexity to their already frustrating experience.

    A good use of rich UI would be a tool to allow a worldwide team of 200 Genetic researchers to interface their collective database. These are specialized, advanced users with well-defined tasks.

    In a down market, you really have to justify the business case for UI- and arguing from an arbitrary standpoint only serves to reduce the possibility that usability practices will be provided at all.

86. “HTML’s Time is Over. Let’s Move On.”

    “DHTML is completely unsuitable for a web application”

    You may wish to think again. Try: http://www.convea.com/demo.htm

    100% web based and fully utilising the power of HTML and browser capabilities for a rich user application. Feedback welcome.

87. David,

    Thanks for the positive comments. The solution is provided either as a LAN installation or hosted as an ASP offering.

    Convea is 100% modular in design and the entire application skinnable. See Preferences and select your theme in the demo. If you require the branding of the solution to match that of your organisational guidelines then we create an additional theme.

    The solution was designed for large enterprises but at present we are targeting the SME space so the solution is applicable to organisation from 100 – 1000 + users.

    To provide a rough indication on pricing, a single server, 100 licence costs £999+vat, with a single server, 1000 licence costs £1,999+vat. Also if you run a non-profit organisation, we provide the solution for free.

    For the solution being IE only, this was really the only realistic business option given that the project started 2 years ago. However Mozilla and Opera have made good strides in the latest releases and we are evaluating them.

    Im not a flash guru, but the major problems that I have seen with flash is that it requires very heavy duty CPU processing power and code maintenance. Anytime a flash anim or demo is run using 100% of the browser window area, it chugs along. Also it would be interesting to see a comparison on how maintainable flash code is and the costs associated. The latter is playing a bigger and more important role in the SDLC and competitiveness of the product.

    Drop me a mail if you require any further info or if you wish to have access to the private demo that allows full entitlements (especially the site manager which is one of the best and most important modules of the solution).

    Regards,
    Adam

88. Wow Adam, you made an incredible application! I don’t complaint it is only for IE, because I think that application like yours that have a focused target must use the technolgy that can better suite the client needs. There is a great difference between public web site and web application. Public web site have to be usable for all audience, but web application don’t.
    The point is: How long does it take to develop an application like Convea (I mean only the GUI not the server-side)? I know that you can do everything with DHTML, but IMHO we need a more pratical solution. When I wrote about XUL is because you can develop RIA in really no-time. Without any previous knowledge about XUL, in 5 hours I developed a GUI for a CMS.
    http://www.cfmentor.com/~faser/xulex/images/faser_one_list_news.png
    It’s easy because you don’t have to spend time in designing the GUI. All widgets are there, ready to use.
    Anyway, my congratulations for your job.

89. > You may wish to think again. Try:
    > http://www.convea.com/demo.htm
    > 100% web based and fully utilising the power of
    > HTML and browser capabilities….

    I’d like to, but I’m not on a Windows desktop computer. I’m also not using Internet Explorer.

    Is there any particular reason it can’t work in Mozilla/Mac or other “standards-based” browsers?

    Later: ah, I see, it took a few years to develop, so I guess it was written as an IE/Win application rather than as an HTML/JS application. I’m still curious what non-standard feature prohibits its use in later “standards-based” browsers…?

    > Anytime a flash anim or demo is run using 100% of
    > the browser window area, it chugs along.

    If you’re turning curves into 1280×1024 pixels fifteen frames per second, then that’s a good number of calculations to make. It’s pretty easy to avoid incurring such a cost though.

    jd/mm

90. The IE vs “standards-based” browser question is a whole topic on its own so I wont go into it here. However the primary decision is a business driven decision. From a business and resource perspective is it worth making the solution Mozilla, Opera, MAC compatible? Given the target demographic of the solution it was decided not (various cost benefit reasons). However that is not to say that the solution has not been developed with the Mozillas and Operas in scope. Given the right scenarios in market acceptance and growth of Linux / Mozilla, you will see a shift on Convea compatibility too.

    Halfbrain was good and shows what has been possible over the last 2/3 years. What you see of Convea is less than 25% of what has been done and what is available to the public. In R&D we have solutions that really push browser and net applications to their limits which will be rolled out over the course of the year.

    Im not a flash guru so cant comment on what is and not possible with that medium fully, however my observations of rich flash apps are not very positive. If someone has got links to ones they consider top rated, please post for review.

91. I don’t think that HTML is “dead”, but I do think that it will have limited use in the future. For some things HTML will continue to be used, such as text based sites like news sites, blogs etc. But for more dynamic “application” level solutions and entertainment such as animation, video I think Flash will become more prominent. I don’t really think it is an argument over what technology will survive, as I do not think it is so black and white. I think it will be more a matter of WHAT technology to use for a particular project, so the needs of the site/applicaiton dictate the medium used.

92. I honestly think the next piece in the puzzle is the thin/thick client as web services gain popularity in enterprise scenarios. Working on a large project for an unnamed pharma company, we were able to condense all the functionality and tools of the HTML web interface into a thin client using web services in 1/3rd the time, while presenting the users of the thin client an interface they were familiar with: a standard desktop application.

    While HTML is perfectly capable in the presentation of information and general navigation of that information, most applications involve large amounts of operations on that information. HTML is unsuitable in this scenario because it lacks the capabilities that a true desktop application can deliver in terms of UI components and richness in functionality of those components. I’ve yet to see a DHTML treeview component that matches what is available developing for the desktop. That’s a dumb example, but you get the point.

    Now we have all sorts of technology to deal with the operations on information and allow us to build interfaces to those operations; but I still think they are all far off the mark.

    Flash locks you into this bizarre timeline/scene/multimedia idea that doesn’t make a whole lot of sense when building applications. SVG is one step better in that you still have a layer that can be generated dynamically at the server and provides all the right primitives you need to build components that do work like their desktop counterparts. It also let’s you keep the development in a form/screen paradigm that makes the most sense when developing applications, timelines be damned!

    Mozilla’s XUL is the only technology I’ve seen that comes close to the ideal; but it still falls a little short. If they’d add support for web services, being able to push XUL to the browser; we’d be a lot closer to the right ideal for modern web based applications.

    In summary, HTML is fantastic for information presentation, but sucks for building interfaces that operate on that information.

93. What about WebObjects?

    http://developer.apple.com/webobjects/

    WebObjects is Apple’s Java powered Java server application building environment. Now you can offer Java applications as standards-based Web services, as well.

    I know Java has been mentioned before but this is an interesting way to bridge different technologies together into a tidy package. The fact that it can be “in browser” or not opens up the possibilities in both directions.

    Recently a friend forwarded a link
    http://www.apple.com/webobjects/resources.html
    to me that included some impressive examples. From small and large scale to the Navy this has opened my mind to Apple. In fact WebObjects appears to work within most environments.

    Maybe this is a step in the right direction?

94. > > I’m still curious what non-standard feature prohibits its
    > > use in later “standards-based” browsers…?
    >
    > The IE vs “standards-based” browser question is a whole
    > topic on its own so I wont go into it here. However the
    > primary decision is a business driven decision.

    Thanks, Adam, but I was more interested in the technical reasons than the marketing reasons.

    I haven’t been able to get under Convea’s hood on my current installation, but am still curious about what prevents its use outside of IE/Win…?

    jd/mm

95. Andrei, your answer is very close to the mark. There is nothing locking Convea to IE that could not be done in the new alternative browsers, which have matured over the last 6months or so.

    The main question is that the amount of time, resources and testing that would be required to optimize the solution for these latest browsers. This would add considerable overhead for a very small percentage of the browser market, especially more so in the corporate and business domain where estimates show IE holding 95%+ of the market share.

    So in summary, technically very little stopping the solution being tailored to work on the latest alternative browsers, but from a business perspective, no driver (yet). If the market shows a shift in browser demographic, then you can be sure that Convea will also, until then win/IE is the only realistic and feasible option when developing such a solution (I know that a lot of people will argue otherwise, but this again is a whole topic on its own… if you wish to discuss in further detail, please drop me a mail!).
    Posted by Adam Smith at February 11, 2003 01:10 PM

    Thanks, Adam. Would I be correct in understanding what you said as “There is nothing technically that prevents Convea from working in a browser with better support for ‘web standards’ than IE/Win, but we just haven’t tested the better browsers yet”?

    jd/mm

96. A little belated, but… Adam: your application is not just HTML. It’s not cross-platform. Ergo, it does not achieve the goals that are intrinsic to replacing HTML, neither does it really meet the rubric of an HTML-fronted application.

    Anyone can write a Windows/IE-specific application solution that has a ‘rich’ and ‘reactive’ user interface. The challenge is bringing it to everyone else.

97. I know I’m kind of late. But I feel I need to clear up some misunderstandings/myths about XUL.

    Myth #1: XUL is a Mozilla only affair

    Fact: XUL is markup like HTML and independent of the browser (although not yet submitted to W3C or standardized by another forum). To proof my point check out Luxor XUL – a open-source XUL motor in Java using Swing or SWT online @ http://luxor-xul.sourceforge.net

    Myth #2: XUL replaces XHTML or XForms or SVG

    Fact: XUL is XML as is XHTML and SVG and XForms. All four nicely fit together (although some clean-up is needed) and can easily be styled using a single technology, that is CSS (Cascading Style Sheets).

    Conclusio:

    XHTML is excellent for styled (rich) text but fails for rich user interfaces (e.g. trees, tables, etc). This is where XUL (XML User Interface Language) comes into the picture. Along with SVG for 2D graphics XUL and XHTML form a perfect trio for creating rich desktop apps in XML.

    For further reading check out some of my presentations:

    * XUL – Beyond Swing and HTML: Building Rich, Cross-Platform, Zero-Admin Desktop Apps on Open Standards Today @ http://luxor-xul.sourceforge.net/talk/jug-oct-2001/slides.html

    * Luxor: The “Linux Kernel” for Desktop Apps – Uniting XUL, SVG, HTML, Velocity, Web Start, XSL/T, Python and more @ http://luxor-xul.sourceforge.net/talk/vanx-jul-2002/slides.html

    * Spice Up Your XML UIs with SVG: Create High-End 2D Graphics Using XML @ http://luxor-xul.sourceforge.net/talk/jug-nov-2002/slides.html

98. > This is all very good. Can you point me to some
    > place that has a demo of a XUL app that would be
    > on the order of what we’ve been discussing?

    Did you browse over my XUL presentations? I thought there are packed with examples, aren’t they?

    Anyway, check out Active State Komodo for a “Amazon”-like XUL killer app online @ http://www.activestate.com/products/komodo/

    Or how about my very own Venus Application Publisher (Vamp) online @ http://vamphq.com/screenshots.html

    Finally, stop a the XUL planet for a first-class, free example packed XUL tutorial online @ http://www.xulplanet.com/tutorials/xultu/

    As a bonus you might wonna check out Neil’s 101 things that the Mozilla browser can do that IE cannot online @ http://www.xulplanet.com/ndeakin/arts/reasons.html

99. I’m also late to the discussion, but I’d like to introduce yet another tool into the mix: I develop a client-side DHTML framework called “netWindows” (http://netWindows.org) that addresses what I believe are all but the author’s gripe with DHTML, save local filesystem access.

    netWindows is DOM based, so anyone with a >= 5.0 browser can use it (and we mean anyone, it even runs on Konqueror and Safari); it solves the bandwidth problems by providing mechanisms to support seperation of data and presentation transport (e.g., send the widget definition, then send it’s data, making the first reusable); it provides totally degradeable “inline constructors” for those concerned about accessability; and it more correctly breaks up the application. Interface state is maintained on the client side while data state and manipulation is maintained on the server.

    Here’s what we don’t provide: a departure from the standard, open tools we know and use today that have had so much time, effort, and mindshare invested in them. We just try to make the more effective tools for doing the kinds of things that web applications are already good at.

    There are others in the DHTML community working on similar tools that fill some other (related) needs, but there’s an overwhelming sense that we’re finally “there”. We can finally convert on the promise of the truly open tools that are already deployed.

    And now we want to throw it all away for proprietary “thin clients” that perserve very little of our existing investments?

    Hmmmm. I thought that was the compelling reason to develop web apps in the first place…

    I’m heartened to see the author recognizing the problems netWindows is designed to address, even if he comes to different conclusions about how to get to a resolution. All I propose is that we not give up on (modern) DHTML just yet. We’ve only started scratching the surface of what’s possible.

100. no combo-box huh?

     http://alex.netwindows.org/cvs/docs/widget_test_pages/combo_box_test.html

     It is currently being used in an application to incrementally match (at runtime) on ~10,000 rows on moderate hardware (~300MHz windows boxen).

     And we’re working on the “data grid”:

     http://alex.netwindows.org/cvs/docs/widget_test_pages/data_table_test.html

     We have a version with resizeable column support in CVS, but I wasn’t happy enough with it’s performance to get it into the next release.

     Oh, and both of those widgets are “degradeable”. Don’t have DOM support? No problem, you get a regular HTML select box and a normal HTML table in that case.

     As for client-side data manipulation: local filesystem access is over-rated in many cases. People like web applications (like webmail, etc…) because it frees them from the problems associated with “oh crap! I left that file on my worstation at home!”. Which is one reason that web apps, as reviled as they are by UI folks, work.

     So we propose what CS people have often do when backed against a wall: make it a little bit more asynchronous. Let the client manipulate their data on the client side and have the client simply tell the server about the changes at it’s lesiure _without_ the need to refresh the entire interface.

     The W3 may not have all the answers, but that’s not their job. They provide the platform, we provide the apps. Time to roll up our shirt sleves and see what we can really do with what’s available before we make the classic computing mistake of forgetting all of the advantages that caused us to flock to the platform now falling out of favor.

     The web took off not because it was perfect, but because it provided us with lower barriers to entry. Are web developers ever going to replace true stateful client-server interaction? No, but that was never the point. Complaining that somehow the web’s failure to do so is it’s achilles heel really isn’t apropos.

     As for Curl, there’s no client for Linux (or any other Unix). They want us to really take them seriously as an HTML replacement? Puhleeze.

101. Andrei:

     Feedback is always welcome. Be as critical as you like. My email address is alex@netWindows.org .

     As for the thin client thing: I’m not arguing against thin clients at all, just saying that we shouldn’t throw out the think client we’ve got (web browsers) for thin clients that not everyone has. For a lot of things, an un-adorned browser is the wrong tool. I’m all about the right tools for the job. Want more than HTTP can provide? Need a stateful network connection? How about local file storage? Then get out of the sham of providing your app over Port 80 altogeather. Let’s stop kidding ourselves: once you jump off of HTTP transport of (X)HTML markup, you’re no longer developing a web application. It’s no longer open, it no longer carries the advantages (and disadvantages) of the web. Calling things like applets, Curl apps, flash apps, etc.. “web applications” is just so much mixed metaphor. It’s like saying that the KDE app I installed the other day is an “FTP app” because that’s how it was delivered.

     Incidentally, my criticism of Curl isn’t theoretical. I don’t run Windows (of any variety), so I simply can’t use it. It may be a bood product, but it’s not helping me any.

     David:

     I’m not implying that you made up the requirement for local filesystem access. Some days I want nothing more than the ability to shove data structures onto a local disk from a browser. Browsers suffer every day at the hands of a stateless sandboxed protocol, but they succeed in spite of it. The history of the web isn’t one of elegance, but rather one of ugliness and stupidity. But that doesn’t make HTTP/HTML inherently bad. They have distinct advantages when it comes to that most precious comodity: developer time. If I want my users to have a great UI that just _works_ on their desktop (Windows or Mac or Linux), then I’ll ship them a PyQT app. If I want to do it in half the time without getting on the upgrade treadmill, I’ll make it a web app and swallow the UI problems. It’s a choice businesses have been making for a long time for good reasons. There’s no UI panacea, using Curl for app development isn’t suddenly going to make thousands of developers more aware of end user experience than they have been using HTML.

     Web UI’s continue to suck. I’m afraid that’s going to be with us for a long time, and toolkits like mine only get us so far. But oftentimes that’s far enough. I don’t dissagree that the web has limitations (and we seem to agree on what they are), I just call for caution in throwing out the bathwater without looking what’s in it first.

102. “”netWindows is DOM based, so anyone with a >= 5.0 browser can use it (and we mean anyone, it even runs on Konqueror and Safari);””

     but not Netscape 7.0 which is clearly adept at DOM handling, not Opera 7.0 at all (crashes it)

     sounds like an IE only implementation – I don’t use Safari or Konqueror…

103. Anyone seen DreamFactory?

     http://www.dreamfactory.com

     Looks interesting, I’ll play with it over the weekend and report back. The founder, Bill Appleton, was the creator of SuperCard.

104. Amazing to me how wrong this article was now that we are in the future…

105. Hi Annette,

     I totally agree how wrong it was. However, is it?
     The spirit of the article is that HTML will never be as powerful, performing, or rich as thick clients are at any given time.

     It is amazing how far HTML and it’s siblings (JS and CSS) have come since this article was written. But at the same time thick client technology has also advanced. We’ve moved on from Flash, but now we have Objective C/Cocoa & XAML/.NET for desktop, mobile and tablet. Further there are still security and peripheral issues that still limit what HTML can do compared to thicker technologies. Yes, HTML has gotten so much better and it survives well and does somethings that are totally appropriate. But at the same time, it cannot nor should not solve all our GUI needs.

     But yes, man! was I wrong. 😉

Comments are closed.