Boxes And Arrows : The Design Behind the Design

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.

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

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.

“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.

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.

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

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

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.

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.

“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.

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.

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.

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.

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

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

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.

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.

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.

Finally, an article on Boxes and Arrows that I actually agree with whole-heartedly…

“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?”

The environment for the future I think is a simple return to desktop apps, with back-end networking and “web services” now an assumed core function.

The whole HTML/Web Technologies piece fueled lots of development in the server technologies and got everyone networked, simply because the Net was cheap, fast and relatively easy to develop for. This is when compared to the effort to creating a desktop app across multiple platforms that handled the network pieces in its own code base and had to code its own interface elagantly.

If Amazon.com had made a compiled desktop app back in 1996, the amount of overhead to create, test, code the networking piece, etc., on top of making the store’s offerings using its own set of needed interface controls not offered by the OS APIs, would have been too much to handle for a start-up like them. Then there’s the problem that forcing users to “install” the desktop app would have shut out more than 50% of the potnetial users right off the bat at that point in time.

But there’s nothing inherent about what Amazon does that says they can’t build their own application that is designed to do nothing but let people buy online specifically from Amazon. Point being that doing inside a web browser versus their own compiled desktop app is only an engineering and business decision. There’s nothing in the technology or code writing itself that forces Amazon to go one direction over the other.

And if they did create their own dekstop app, imagine how elegant the user experience ***could*** be! Combo Boxes! Undo! Copy and Paste! DRAG AND DROP!

When returning to desktop apps, just note that what should happen soon is a return to building real applications on the desktop with an assumed network component that can use HTML/Web Services pieces smoothly integrated.

Many “smaller” applications have or had already begun to do this. Windows MediaPlayer, the IM programs, custom ISP Web Browsers (MSN Web, SBC Yahoo! Browser), QuickTime Player, RealOne, WinAmp, GameSpy, iTunes, Outlook, Napster and even some corporate apps.

I’m sure most people know they do so by coding their app, then shoving in ActiveX pieces from Windows, or using other .NET components. (Sidenote: I’m shocked and amazed how long Apple has ignored this piece for their OS by the way. If Apple would get off their tails making silly programs like Keynote and focus on hardcore OS web services that allow developers to have to write code twice for Windows and Mac, things would be a lot farther.)

But the future as far as I can tell will be a return to desktop apps. Thank goodness! And in that return, networking and web services will simply be at the core of every OS so that every developer will not have to reinvent the wheel. (At some point in time, this will be true. I just don’t know when.)

Rendering of HTML can be used for heavy content if needed, but web forms? Please… let’s get back to using real dialog boxes again, with an an app that uses real widnows and real interactions with real UI widgets that have real behaviors and dynamic screen redraws for a real user experience.

There are two companies that could rebuild their products as real desktop apps to start the snowball effect of returning to real applications on the desktop:

Amazon.com and eBay.

If they ever did, I predict we’ll all finally leave web browsers.

Kill that damned BACK button already.

Andrei

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

“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.”

Define “robust.”

Further… what is the point of forcing users to install Flash to achive an interface inside another application (the browser) that can be accomplished by simply coding up a real desktop app? (Sure, Windows at the core API level doesn’t have all the eye-candy of some of the vector like things in Flash… but more and more of that eye-candy is available now in both Windows and Mac OS and as time goes on, more will be added. Besides, I don’t consider eye-candy on par with “robust.”)

Seems like Flash is simply doing things in a different way if the goal is to create a real application, but with Flash you go without all the OS services you’ll need to create a truly “robust” user experience.

If Flash is so good or the next level, why not code Photoshop in it? Or Outlook? Or MS Word? Or MediaPlayer? Or any number of “robust applications.”

Why indeed?...

Andrei

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

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

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.

”...I would build Media Player and Outlook in Flash, and not Photoshop … 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.”

I guess this begs the question…

How does building the app in Flash ***inherently*** make it “thinner” than building it for real?

Andrei

Yes, I’m an Adobe employee. I know Flash “apps” can be exported as stand alones, etc. That’s not really what I was getting at as the point of my post.

”...if you are or are not i really do not care i just want to say SVG SUCKS!”

Sounds lke troll bait. I expect a bit more from people who read this web site.

Andrei

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.

“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.

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.

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

“As I was reading the last comment, my thought turned toward “hybridization”. What would happen in a hybrid of HTML and Flash.”

I still don’t understand why not just code whatever your product is as a real app, in something like C++ or whatnot? Why spend lots of time and effort in learning and developing some strange sort of hybrid in Flash/HTML and whatnot?

It seems that mostly what is missing from the OS APIs are cooler “eye-candy” sorts of operations, which is being addressed by every release of Windows and Mac OS year over year, and much of the network services that a web browser provides is also being addressed more and more at the OS level. Enough so that a browser or Flash is really just in the way.

And then there’s all the services the OS APIs *do provide.* PRinting. FIle Systems acces. Memory handling. etc. Along with all the power that you get as a designer to take over the user experience in a more meaningful way than by being limited to the poor web browser UIs or limited Flash abilities. (Beyond the fact you have to re-create way too much core interface functionality when building Flash apps, which too many people seem to have more fun adding their spin on than just coding standard controls. This drives me as a user nuts. I just want a SIMPLE FREAKING SCROLLBAR ALREADY in all the Flash apps. There… I got that off my chest.)

What about the development environment of a Flash app is so appealing? Everything it lacks already exists in just learning how to code for the desktop. And by the time Flash DOES add all of those things, guess what? It’ll be just as complex as coding for the OS in something like C++.

So why not just code it for the OS from the get go? The cross-platform issues are real, I understand, as is the problem of having people have to “install” an desktop app. But those are very simple problems to get around with a little planning.

If you take a look at some of the poker programs out, like Paradise Poker for example, you’ll see a real coded app that takes advantage of networking functionality at the OS level, along with having a real user experience on its own level without being a Flash kludge or Java kludge.

Now, it’s UI has a lot to be desired from my point of view… But really, why would even want to build this kind of app in Flash? This is the real kind of “hybrid” application I think you are referring to, and it is indeed the future. But it’s a real app that uses all the power of networking, and all the services the OS offers and has a UI deisgned for its audience.

This is where it’s all going in the future as far as I can tell.

Engineers are going to be forced to get back and doing what they did in the 80s and 90s. Code real apps. And we’re going to have to get back into designing those apps with all the complexity a desktop application requires. We’ll get back dealing with keyboard shortcuts, and undo behaviors, and how to best deal with windowing systems, and keyboard input, and focus and state issues, and how the mouse works with direct manipulation in the task…. and a myriad of things all lost in the latter half of the 90s with “web applications, web content and web e-commerce stores inside a browser.”

And it’ll be a good thing, as we return back into a field that requires more hard-core discipline than the latter of the 90s seemed to require.

The whole latter of the 90s in the field of user interface design reminds me of what happened in a different field in the latter half of the 80s and beginning of the 90s. That field is Print & Publishing, and it got sideswiped by Desktop Publishing.

When DTP came around, anyone could be a “designer.” And lots of people not qualified as such called themselves designers. All sorts of incredibly poor design occured in that period as everyone was getting themselves hired as a designer and getting paid for it. But design on the whole suffered through a horrendous time as typography, color and all sorts of basic desing principles got lost in the technology, as much the technology was lacking at the same time. But getting a computer and installing some programs and fonts was incredibly cheap when compared to doing it the old way through machines that costs hundreds of thousands of dollars. It finally evened out and got back on track somewhere around 1997 or 1998 as the technology caught up with what professional designers really needed. IMHO.

We had the same problem in the latter 90s with the Internet and the web browser. So much was lost as everyone got their hands on all this technology, and were able to build “application like products” on the cheap using HTML a server and a web browser as the base. And the technology suffered as all in terms of providing an offering to handle all that is needed to build real apps with a real user experience. We are just now getting out of this phase, and I predict we’ll all get back into the real deal again: desktop apps. Now, the technology is catching up and farther ahead, and NETWORKED. The networked part changes everything.

If you want to design a real user experience, why use something that is built on top of the thing you really want to control? Why not just build on the OS, where you want real control, rather than inside an environment built to sit on of the OS?

Flash is purely a distraction.

Andrei

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…

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 ).

that last sentence should read…

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

;-p

sh

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.

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

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.

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

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.”

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.

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

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

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

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.

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

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.

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

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.

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.

“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.”

You think that is inherent to a web application” or Flash type app? It’s not. In most web applications, you intall the main app on a server, and everyone access the main app via a connection of some sort. So when you upgrade the main app, everyone is forced to use the new version.

How is that any different than FORCING every user to download the latest version the moment it becomes available if you have a desktop app installed? Effectively, it’s not.

Again, download a game app like Paradise Poker and watch that they do EXACTLY this. They force every single user to upgrade when that upgrade is available. You, the user, have no choice in the matter. Everyone uses the same version at all time. Always.

“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.”

Once again, this has nothing to do with being a traditional desktop app. If the app you are working understands “networking” then you can make it behave accordingly.

Look, the bottom line is this: Code is code. Making the code work to BEHAVE in a specific manner means you just have to CODE IT. Being a web applications or desktop app has nothing to do with that equation.

The question lies in how much time and effort you want to invest in coding it. The only thing I’m claiming is that if you simply go back to a desktop app, you as the Interface Designer, get complete control back on designing the user experience because you can take over the windowing system, get at the hardware, get printers, the file system, and memory in the machine. If you’re goal is design a top notch application that needs all these things, why bother with Flash?

“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.”

This is always the trickest issue. Bottom line is that sure, using a technoloy like Flash, you gain some ground in that Macromedia is taking the heat for making it work on every platform. But you also lose many services at the OS level that I feel need to be put back into application design that was lost in the 90s.

Further, I feel the technology will catch up in this regard such that this cross-platform issues is less and less of an issue. Already you are seeing that getting access to network APIs on Mac and WIndows is more straight forward than it was back in 1996. Right?

And then there’s always the notion that Windows is 90% of the market, so who really cares. I mean… really? (This is coming from a person who own a Mac and has been a die hard Mac geek for ages.)

Andrei

“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.”

A mainframe model does not mean that you can’t have a real desktop app on the front end designed to handle everything in the manner you deem most usable.

Even if the front end is very thin, by having it be a real desktop app, the level of interaction you will be able to get of out it is far more useful than curl or flash or whatever else is being coded out there to get around just coding a real app.

By the way… I don’t mean to argue you SHOULD build it as a desktop app at this point in time. I completely understand using Flash or Groove or Curl or whatnot and how much cheaper, faster, easier to install, etc it is right now at this point in time. I used much of those things when I was building web applications myself, so I understand the reasoning.

But I also know that using those technolgies was because there’s not a lot of desire to invest engineering resources into just build a robust desktop app with a robust backend component, and spending time solving the problems revolving around mixed environments and variables. Using Flash or Curl inside web browsers or whatever is fine. That’s not my point.

If we are talking about designing real user interface with robust user experiences and how to do that for the next generation, there’s no way I think you can argue that building a system that sits on top of an OS will get you the best result as you are always developing to the standards of the environment that is sitting BETWEEN you and the OS. You are one level removed and limited to the environment instead of getting that middleman out of the way.

An example: Imagine if WebVan had actually built REAL DESKTOP app for their shopping service. The experience of shopping would have been dramatically imporved over anything you could have built in Flash, Curl or whatever. Drag and drop lists, mutliple selection, better printing facilities, UNDO! Copy and Paste! Dynamic screen refreshing. Modal states and multiple selection and dialogs!

So much could have been improved. Now imagine taking that desktop app, investing some their hundreds of millions of dollars into grabbing WindowsCE or some light-weight OS, and building that desktop app to best run using a stylus and a flat screen display (with computer on board) with no keyboard. Now put that desktop app (which can auto update itself like Paradise Poker can), pre-install on this hardware device that is a flat screen and works with the stylus only, and HANG IT on your refrigerator. Now when you open and close refrigerator, you can interact with app in the context of when you think of it, that being when you are getting food out of the fridge.

How much more successul could a comapny like WebVan have been had they designed a real product in the context of what their users needed? The shopping exeprience on WebVan was horrendous (as is the case with Amazon these days, by the way), and sure, they overspent, had a poor business model, yada yada yada. But my point is the usefulness of the prodcut offering was completely botched by the fact they limited themselves. And doing it in some middleware technology is only moderately better, IMHO. Might as well just make a real app.

I’ll shut up now… I promise. 8^)

You should download a program like Paradise Poker and watch how it behaves. The UI is gawdy, and much the behaviors are a bit whacy, but the concept of a networked app and the issues there is rather interesting.

Andrei

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….. ;-)