This evening at Max, Adobe presented their annual Sneak Peeks, which are demos of new technologies that they may or may not release in the future. Two of these new technologies pertain to Ajax. One is a tool set that is intended to help developers integrate pre-made Ajax components into their sites. The other is a hosted service that enables developers to quickly and easily compare the way that their pages will render in different browser/platform combinations. In other words, both of them help to compensate for some of Ajax’s more significant weaknesses.

The sweet irony here is that both of these technologies leverage Flex. That’s right - one day soon Ajax developers are likely to be using Flex applications to help them solve some of their more thorny development problems.

Here in the US in particular, we’re in the midst of a season with lots of opportunities to send invitations and to take surveys, and I want to tell you about a very cool new way to do both: Yarp. It’s a Ruby on Rails application built by a couple of friends that takes an entirely new approach to invitation and survey creation. It does not require logins, it only allows yes or no answers, and it is fun to use.

When you test drive Yarp, you’ll notice that the UI is slick, but you’ll also no doubt recognize that it could be even slicker if it were done in Flash. You may well wonder why the developers didn’t do it in Flash. Well, it so happens that Flash is against their religion.

You may be wondering why I’m even talking about Yarp when its creators are anti-Flashers. After all, I’ve made no secret of the fact that I think it is wrong-headed to continue building Web applications with those unholy amalgamations of mismatched technologies known as Ajax and DHTML. Well, it so happens that I believe in acknowledging good work no matter who does it, and no matter what technologies they use to get it done. I believe that people can have differences, and even tell each other that they are wrong, and still appreciate the good in one another. In spite of our religious differences, I think these are good guys who do great work, and I don’t mind saying so - any more than I mind saying that their choice of UI technologies is really poor.

So, I plan to continue using Yarp, and I plan to continue enjoying it. Give it a spin, and then let me know what you think.

I have been using Google’s new browser for about three weeks now, and so far have found it to be very good. I have also found that Chrome makes a very good argument as to why we need to get away from browsers for delivering Web applications.

Before I go any further, let me mention some of the things that make Chrome really good for browsing websites. Perhaps most important is the way it isolates each tab, so that if one tab crashes the others aren’t affected. This feature has proven to be beneficial on a number of occasions, as JavaScript-heavy sites have crashed their tabs while allowing me to continue working with the sites that were open in other tabs.

Next in importance is the way each tab swallows its own pop-ups, so that when you close the tab the pop-ups go with it. The third most important feature is its speed - it appears to me to be even faster than Firefox for most sites. This is just an impression, as I have not performed any timed experiments, but Chrome is clearly faster than IE7.

Chrome also has some little convenience features that I like. For example, my current project forces me to use three different webmail clients during business hours, so I like Chrome’s combination of the thumbnails of recently visited pages with the little plus-sign button for opening new tabs: I can eat my breakfast with one hand and open all of my webmail clients with the other in just a few clicks of the mouse.

On the other hand, I do not like the way Chrome handles downloads, because it does not give me a choice as to where to save the file; it automatically puts it in My Documents/Downloads, which is a folder I never use on my own initiative. So after I download a file I need to move it to where it belongs, which is a nuisance because I need to download a lot of files in a typical work day.

I have also found Chrome to be fairly buggy with certain Web applications. For example, one of the webmail clients I need to use every day is CommuniGate with the LookOut skin. This application works great in Firefox, but it periodically crashes in Chrome. At other times it doesn’t exactly crash, but it decides I’ve looked at enough email messages and won’t show me any more till I log out and log back in. Also, I am not able to attach files to messages in Chrome about 50% of the time; the rest of the time Chrome just scoots the message window to the lower right corner of the screen and ignores my request - almost like it’s having a tantrum. Again, I’ve never experienced any of these issues in Firefox.

This difference between Firefox and Chrome leads me to the main thrust of this article: Web browsers are great for surfing the Web, but they do not make great containers for Web applications. Do not misunderstand me - I freely and enthusiastically acknowledge that many great applications have been built to run in Web browsers. However, I also believe that the browsers prevent these applications from being as great as they could be.

The aforementioned bugginess in Chrome is a case in point. You can build a fabulous application that works great in all major browsers until a new browser version comes out - or a giant like Google releases a completely new browser - and suddenly your application is crashing for a significant percentage of your users. Very ugly.

Another issue with browser dependence is that it takes control away from the developer. You cannot guarantee that your application will look the way you want it to look or work the way you want it to work, because you cannot control your users’ choice of browsers.

One example of this problem can be seen in the different ways that Google Maps works in different browsers. In planning a recent family vacation to Canada, I looked up an address on Google Maps in Chrome, and I got a map of North America: not very useful. I entered the same address on  Google Maps in Firefox, and it pinpointed the exact location on a close-up street map: exactly right. Click on the thumbnails below to see full-size screen shots of this phenomenon. (Depending on your browser, you will either get new browser windows or new tabs in your current window.)

Another example of the discrepancies between browsers is shown by trying to attach a file to a Gmail message. In Firefox and other browsers, when you click on the “Attach a file” link you get an input text field with a “Browse” button to the right of it.

In Chrome, you get an input text field that says “No file chosen” and a button to the left of it that is labeled “Choose File”. Some might argue that Chrome’s way is better, but it is certainly not standard, and it is significantly different from the way other browsers do things.

My third and final example may seem trivial to some, but it is near and dear to the hearts of many: different browsers vary widely in the ways that they interpret CSS. One example of this is the footer of my website. The markup is very simple and standards-compliant, but the browsers don’t agree as to how it should be rendered. Chrome is the biggest offender here; it renders the font much taller and somewhat narrower than the others. While this difference is merely aesthetic in my footer, it could throw off the entire layout of a more complex user interface. Click the thumbnail below for a full-size comparison.

While Chrome represents an improvement over other browsers in several respects, it also highlights some of the main reasons as to why Web browsers are suboptimal as application containers. Plugins (most notably the Flash Player) represent a step in the right direction, because they provide a measure of cross-browser consistency. However, the best option is to get out of the browser altogether. This may require users to install a runtime such as AIR, but the potential benefits far outweigh this trivial inconvenience.

Don’t you love acronyms? I probably could have come up with a more descriptive title for this post, but the acronyms were just too much fun to resist. The disadvantage is that the title probably leaves you wondering what this post is actually about. Well, I’ll tell you. It’s about issues that Internet Explorer has in dealing with certain kinds of files - specifically, any kind of file that IE passes on to an ActiveX control - over HTTPS. Examples of files that leverage ActiveX in IE include MS Office files and, tragically, Adobe Flash files (SWFs). Check out Microsoft’s tech note on the subject for more details of this feature (MS insists that it is not a bug).

This week my team put the first iteration of our custom Flex-on-Alfresco application on the internal QA server. Unlike our Dev servers, which use HTTP, the QA server uses HTTPS. This didn’t cause any issue in Firefox or Safari, but on IE the QA testers were unable to log in to our application. When we looked into it, we found that the Alfresco Flex SDK was throwing an error of type ApplicationError - which basically means that something went wrong in the request/response loop. The stack trace was similarly unhelpful.

When we analyzed the communication using Charles, we could see that the server was indeed sending back a valid response. So if the server was sending back a valid response, why did the Flex application keep telling us that it wasn’t getting the response? I had my own suspicion, and it was confirmed when I analyzed the response headers using Live HTTP Headers.

The reason for the failure is that, by default, Alfresco’s HTTP/HTTPS response headers use the “no-cache” setting, which is one of the settings that causes IE to fail. Essentially, IE needs to put the file in its cache in order to hand it off to the ActiveX control (in this case, the Flash Player). Since IE received the “no-cache” instruction, it couldn’t put the file in its cache, so it had nothing to hand off to the ActiveX control but an error message. As it turns out, we had coded our Flex UI in such a way that we would not let people access the application unless we got a valid response to our login request. Call us sticks-in-the-mud if you like, but we are not budging.

Alfresco is not the only server technology that puts in IE-killing headers by default. As you can read in this flexcoders post, Spring defaults to similar settings. In fact, this is not an unusual problem for applications that need to run over HTTPS; after all, if you are building a dynamic application that is designed to serve truly fresh (if not real-time) data, then it seems to be common sense to tell the browser not to cache pages. However, no one ever accused IE of running on common sense.

How do you diagnose this issue? As mentioned above, the Alfresco Flex SDK gave us the generic AppicationError message. When using straight HTTPService calls, you are likely to get “Error #2032: Stream Error” or simply “HTTPError” - which are similarly unhelpful. The clearest way I have found to diagnose this particular issue is to run Live HTTP Headers, which will tell you immediately what the response’s caching instructions are. If you are experiencing an IE-only problem over HTTPS and your server response header says “no-cache”, then you know why your Flash or Flex or other ActiveX application is bombing.

Solution: We decided to turn off the no-cache settings at the server (Apache) level in order to allow QA testing to go forward, and that did the trick. However, before we go live we may decide to alter the settings programmatically in Alfresco, and this document appears to describe how it is done. If you are working in Spring, you might find the aforementioned flexcoders post helpful. If you are uncertain as to which caching instructions to put in your headers, this blog post by Marc Speck of Switzerland includes a helpful list of the HTTPS cache settings that do and do not work with ActiveX in IE.

Thanks to everyone who attended the Putting a Flex Face on Alfresco webinar. I hope you found it useful. If you didn’t get to attend the live webinar, that’s OK: the good folks at Alfresco recorded it, and you can view it here .

I cleaned up the code a bit and added some comments, and you can download it here .

Let me know if you have any questions, suggestions, etc.

Enjoy!

=====
UPDATE:

I added the Alfresco SWC  and source to the source code distribution for the sake of convenience. You’ll still need to set your Flex Project properties to point to them, of course.

In case you haven’t heard, Alfresco is an impressive open-source content management system. And of course you probably wouldn’t be reading this blog if you didn’t already know that Flex is a killer technology for building world-class user interfaces. Seems like someone should put the two technologies together, no?

As it turns out, Alfresco has released a Flex SDK that makes it really simple to integrate a Flex UI with an Alfresco CMS installation. If you want to learn more, check out this webinar tomorrow at 12:00 Eastern. We’re going to build a Flex application and integrate it with an Alfresco back end right before your very eyes.

In a prior post I promised to provide some thoughts on the AdvancedDataGrid and XML. Well, that post was written about 4 months ago, and I’m finally delivering. I’ve put together a simple demo to show how the AdvancedDataGrid works with XML data:

Each of the first three tabs works with a different XML file. Each of these files contains essentially the same data; the differences are in the way the data is structured. The fourth tab illustrates what appears to be an error in the Flex documentation.

If I try to explain the differences between the XML files, this will turn into a very long post. A code sample is worth a million words, so I’ll leave it to you to explore the demo (right-click on the demo to view and download the source). Let me know your thoughts, comments, corrections, questions, etc.

A very interesting article in the New York Times describes a paradox of medical technology: Health care providers bear most of the cost of the technology, but their share of the savings is meager and trickles in slowly (insurance companies reap most of the savings). Thus, the doctors shell out large sums of money for very little return.

Well, a few years ago I helped to build SeginusMD, and I still do some consulting work on it. It was built primarily with ColdFusion and Flash (though it does have some .Net components) with a SQL Server 2000 database and it is really quite good. Since it’s Web-based, the practitioner’s up-front costs are quite low, and upgrades are automatically included in the relatively modest annual service charge.

Obviously, this is a plug for myself and for some of my favorite technologies, but I feel justified because I really believe in the software. So if you know of any healthcare providers who are looking to move from a paper-based system to an electronic billing/appointment/records system, do them a favor and let them know about my favorite medical practice management system.

OK, since this is my first post in a long time, perhaps I should feel ashamed for not writing something of a technical nature. Don’t give up on me; I’ll post something technical soon.

I had a good time at FlexManiacs. It was great to see some old friends and make new ones. I also got to sit in on some interesting presentations.

I’ve posted the files from my own presentations as follows…

Introduction to ECMAScript for XML (E4X) - This download includes a PDF of the slides, plus two Flex 3 projects. You can download the complete distribution here. If you would like the complete application from which the demo is derived, you can grab it from the Manifold project page; it provides a better example of how to manage data, but it doesn’t do as much with E4X.

Building Accessible Flex Applications - This download includes a PDF of the slides and a Flex 3 project that demonstrates the accessibility techniques and features discussed in the slides. Download it here.

Making Large Applications Manageable with Modules - This includes slides only. I did not get to complete a demo for this presentation, but I hope to have it done soon. Since several of the attendees had questions about mixing Cairngorm and Modules, I will make it a Cairngorm application. Meanwhile, you can still get the demo application from last year’s Modules presentation here.

Thanks to everyone who attended my presentations - and special thanks to those who provided feedback!

In his latest Alertbox column, Jakob Nielsen discusses a research study that could prove to be invaluable to our understanding of how users behave on the Web. The great thing about this study is that it tracked the participants’ behavior as they followed their own usual routines, so it gives some clear insight into how people use the Web on a day-to-day basis.

In his column, Mr. Nielsen focuses on the fact that people read such a small portion of the text. Using data from the study, he calculates that on average people read no more than 28% of the text on a given Web page. This helps to add further emphasis to a point of Web usability that has long been established: Keep the text short, relevant, and scan-able.

Another finding of the study that is of particular interest to those of us who are focused on building Web-based applications is the impact that we’re having on the back button. The browser’s back button has dropped to third place in the list of most-clicked items, and according to the study’s authors, this drop has something to do with what we sometimes call RIAs:

A major finding is the decreasing prominence of backtracking in Web navigation. This can largely be attributed to the increasing importance of dynamic, service-oriented Web sites. Users do not navigate on these sites searching for information, but rather interact with an online application to complete certain tasks.

What I would like to see analyzed is the degree to which the look and feel of the application makes a difference here. Most Web applications, since they’re built with Ajax, still look and feel very much like conventional Web pages. It seems to me that users are more likely to hit the browser’s back button in this case, than if the application looks more like a GUI and feels more like a desktop application. Speaking for myself, I still find myself hitting the back button from time to time when I’m in Gmail, which looks pretty much like a Web page. By contrast, it would probably never occur to me to hit the back button if I were using an app like Scrapblog or Buzzword. (I wonder if I could get a grant to study this?)

Ideally, of course, I’d like to say, “let’s put all of our applications on AIR and leave the browser for text-based Web sites.” However, there are those circumstances where zero-footprint is a requirement, and others where it’s just desirable - particularly from a usability perspective - to have the application come up in the browser. For those circumstances, it is good to have some data on how much people rely on the browser’s built-in controls.