John Allsopp has a thoughtful piece that races some old concerns about the new tag set in HTML 5, and how we will ever be able to jump on that train when the cabooze still has IE.old train cars.
It is great to have new semantics for <section> and all, but what will browsers do with these new tags?
John walks through a simple example with the new tags, shows some issues, and then wonders if we could use the existing extension points (attributes):
Let’s invent a new attribute. I’ll call it “structure,” but the particular name isn’t important. We can use it like this:
<div structure="header">
Let’s see how our browsers fare with this.
Of course, all our browsers will style this element with CSS.
In fact, almost all browsers, including IE7, style the div with an attribute of structure, even if there is no such thing as the structure attribute! Sadly, our luck runs out there, as IE6 does not. But we can use the attribute in HTML and have all existing browsers recognize it. We can even use CSS to style our HTML using the attribute in all modern browsers. And, if we want a workaround for older browsers, we can add a class value to the element for styling. Compare this with the HTML 5 solution, which adds new elements that cannot be styled in Internet Explorer 6 or 7 and you’ll see that this is definitely a more backward-compatible solution.
John then goes on to discuss the potential use of the role attribute, and more.
It feels like there are two issues here:
Are new tags the right way to provide new semantic value
Are there work arounds to back/forward compatibility.
Without compatibility, it will be impossible to get this off the ground for many people. What if we mix both worlds, and a shim is put in place to convert the new tags to divs and the like at runtime for browsers that don't support it. Is that enough?
It comes to the age old issue of how "desktop-y" do you make your Web application? Herb believes that having them look like desktop apps is natural. I think that I disagree. I like Gmail because it is a great blend of web-y and desktop-y. In fact, it is more like pine on the Web than Outlook on the Web :)
The best applications seem to nail that blend of both worlds. What do you think?
This is Herb's conclusion:
Most SaaS/Web 2.0 applications today look and feel pretty much the way GUI applications looked and felt like on DOS, before technologies like Windows and OS/2 PM existed. Around the late 1980s, people wrote lots of GUI applications that ran on DOS, but we didn’t have a widely-used common GUI infrastructure that handled basic windows and menus and events, much less standards like CUA that tried to say how to use such a common infrastructure if we had it. So they each did their own thing, borrowing where possible from what seemed to work well for GUIs on other platforms.
Twenty years ago, everyone writing GUIs on DOS designed the UIs as best they could, borrowing where possible from what they saw worked on platforms like the Macintosh and Xerox Alto and Star — but the results were all over the map, and would stay that way until a standard environment, followed by standard guidelines, came into being.
Today, everyone writing rich Web 2.0 applications is doing their own thing, borrowing as best they can from Macs and Windows and others — but the results are all over the map, and will continue to be until there actually is such a thing as a UI standard for rich-GUI web applications. You can see that in the differences between Zimbra and Outlook Web Access. In the meantime, it’s not just okay to borrow from what we’ve learned on the desktop; it’s necessary.
And the question isn’t whether metaphors users already understand on the desktop will migrate to the web, but which ones and how soon, because it’s the whole point of SaaS. The industry will soon be going well beyond Google Apps; with offerings like Office Online already announced for the short term, which puts still more rich-client GUI apps like word processors and spreadsheets in the browser (with functionality somewhere between Google Apps and the desktop version of Office).
Zimbra and Outlook Web Access aren’t examples of poor web app design, but exactly the opposite: They’re just the beginning of the next wave of rich web apps.
I am proud to be able to announce the new currency converter on Yahoo finance. Why? Because it is a perfect example of how a complex rich user interface can be built in an accessible manner.
About 9 months ago my fellow co-worker, the User Experience Designer Graham Beale, and I started developing ideas for a prototype of a new Currency Converter for the worldwide relaunch of Yahoo! Finance.
We wanted Features we haven't seen like this in the Internet so far. We wanted conversion without a page reload, searching for currencies like in the Firefox 3 "awesome bar", total accessibility, much more and of course everything in realtime.
There will be an in-depth article on how Dirk and his colleagues (with a special mention to Artur Ortega who did all the screen reader testing) build the converter on the Yahoo Developer Blog after the holidays. For now, have a look at the code and see the wonderful attention to detail. One of the main tricks they've done can be mentioned already: dynamic re-writing of form labels.
Most everyone knows that Google has really stepped up to the plate by helping many JavaScript library projects host their builds on the Google AJAX Libraries API. Apart from providing a central distribution point for these libraries, the bandwidth cost savings alone go a long way in helping frameworks service their users in a sustainable manner.
Thanks to Vadim Spivak at Google and Dion Almaer (now at Mozilla) for helping to make this additional option available to the YUI developer community. We love that Google is supporting web developers in this way — grabbing YUI files from Google’s global infrastructure is a fantastic option to have.
This is great news for YUI developers who now have a choice of linking directly to YUI via yui.yahooapis.com and ajax.googleapis.com. YUI team lead, Eric Miraglia, has a great write-up on the YUI blog about this and goes into detail on how the framework's users can take advantage of this new hosting option.
jQuery and Amazon CloudFront
With nearly 2.5 million requests per day to the jQuery website, the jQuery project team is constantly on the look out for ways to decrease hosting costs while still managing the growing number of requests for the site's resources. Originally leveraging Amazon S3 for many of their static pages, the project has now turned to Amazon's new CloudFront CDN. The change has allowed for jQuery pages to be globally hosted as opposed to being centrally located in Amazon's Seattle-based S3 hosting center.
In tests, John Resig, team lead for the jQuery project, noticed substantial performance gains based on the switch:
I ran a similar test here in Boston and even managed to see a large improvement. I was seeing latency of anywhere from 50-200ms on Amazon S3, but only a latency of 17-19ms with CloudFront.
What does all of this mean? It means that the jQuery site is going to load even faster than it does now. We already receive some excellent hosting from Media Temple but being able to off-load these static files to the fast-loading servers will only make for a better browsing experience.
In less than 24 hours the project had received almost 2.5 million requests for over 50GB of data. The only drawback is an increase in bandwidth costs but still substantially less than that of a traditional hosting plan. The jQuery project makes use of the Google AJAX API as well and recommends it as choice for linking to the jQuery and jQuery UI libraries.
The hosting is free and what makes it unique to something like the Google CDN is that it allows Ext developers a central access point for their own custom builds.
We are pleased to announce that Ext has partnered with CacheFly, a global content network, to provide free CDN hosting for the Ext JS framework. Cachefly’s globally distributed network and aggressive caching accelerate the delivery of web content like JavaScript and CSS, making for an even faster Ext experience.
In recent presentations, Ben and I have been taking a look back on the rise of Ajax (where Ajax == popularity of dhtml :). At its core, I think it all comes down to UI responsiveness.
When you look at the killer apps such as Google Suggest and Maps, they broke through a set of myths on the Web.
Latency is the killer issue on the Web
We are used to autocomplete in fields and forms these days. However, if you think back to when Google Suggest came out, if someone had asked you whether it was a good idea to do a background request on each key press you may think they were insane. The beauty of suggest is that it broke through and gave great performance. You could do this on the Web.
Rich interactions are not possible on the Web
Again, we are used to applications that allow us to interact with data in a better way. With Google Maps, you feel like you are moving around the map. You are interacting closely with the data. Before hand, we were used to a static view that had us clicking up/down/left/right or zooming around. Every click responds with a wait and a repaint of the entire screen.
This seems crazy. No application framework would ever do a refresh like this, and dhtml broke us out of that box.
This is all pretty obvious, especially when you take a look back at the HCI research on how anything that takes more than a second drives your users batty (and gets them out of the zone). Getting down to 0.1 seconds and your users will feel like they are at one with the app :)
The responsiveness that Ajax gave us opened up the Web for truly useful applications that users could live in without getting frustrated. This bridged us from pages to apps.
We continue to see movement here too. The reason that WorkerPool was added to Gears (Web Workers in the standard) was to give developers the ability to send "work" (run code) to a place that isn't on the UI thread, which is a big no-no for building any kind of responsive application. As we write bigger and bigger Ajax applications, we end up running more code, which competes more with the browser. Having Web Workers in the browsers natively, and available to those that don't via Gears, allows us to build compelling applications.
Add to this fast JavaScript (SquirrelFish Extreme, TraceMonkey, V8), and we can get to a happy place with respect to performance.
So, if the original Ajax revolution was about UI responsiveness, where do we go from here?
I think that we have a few directions that we need to go in:
Productivity
We need to be more productive. We all feel a lot of pain with Web development, even as we get a lot of benefit from the reach and openness. This is pain is the reason that Ben and I are working under a developer tools umbrella at Mozilla. We want to work with the community to become more productive. It is extremely important to do so.
It shouldn't be hard to put together the hundreds of applications that the Enterprise and beyond spend too much time and money on every day.
We shouldn't have to fight the browsers to get things working as much as we do today.
Any ideas on what would help you? We are all ears.
Compelling applications
We have spent a lot of time in the weeds talking about the engine of the car. We jump on a point release of some framework, and argue about the minutia of framework differences.
Maybe it is time to pop our heads up a little and think about how we can build compelling, feature rich applications.
The browser is extending to the desktop more, to give you nice full experiences. The real-time Web is kicking off, and Comet will become a big part of how we develop many applications in the future. It needs to be as natural to us as the simple request/response world that we are used too.
UI latency is only one piece of user experience. There are many others. HTML 5 gives us richer components and semantics to work with. We have been working on different UI paradigms such as the Form History pattern that we have discussed before. Aza Raskin and others have been doing really good work on new paradigms too.
Personally, I think that new input devices are going to create a huge change for us, and the abilities of Web applications. We played with the WiiMote as an input device. We then have multi-touch, which is available on touch pad devices as well as touch screens. Finally! We are moving past the prehistoric inputs where we can point and say "Ug".
I am incredibly excited about where we are, and where we are going. There is a ton of work to do, but people feel engaged. Let's "get 'er done".
Where do you think we are going?
This presentation goes over some of these points, in more detail:
XHR is so 1997. Now it is time for some CSSHttpRequest action, a device that allows you to run cross domain Ajax requests thanks to a CSS hack:
Similar to JavaScript, this works because CSS is not subject to the same-origin policy that affects XMLHttpRequest. Like JSONP, CSSHttpRequest is limited to making GET requests. Unlike JSONP, untrusted third-party JavaScript cannot execute in the context of the calling page.
A request is invoked using the CSSHttpRequest.get(url, callback) function:
Data is encoded on the server into URI-encoded 2KB chunks and serialized into CSS @import rules with a modified about: URI scheme. The response is decoded and returned to the callback function as a string:
Matt Raible has posted on the Ajaxified Body pattern, that loads content into the main area instead of reloading an entire page.
The surrounding template stays put, and the red area changes when you have an action:
This is an old question: "When should you just reload the page?" In the sample application you see the trade offs. Every click causes a red "Loading..." indicator, and just the main area changes. The browser doesn't have any indication that something is happening, hence the need for the custom red indicator. You also then have to implement support for browser history, make sure that direct access works and the like. The positive is that you don't get a refresh flash, but is that enough to warrant the change?
One of the use cases on the page is the rich table component. That should definitely be able to refresh and page without the page changing, but when the main content gets swapped in, I start to question. What do you think?
Matt uses SiteMesh, a great technology that can knit together the look and feel, and can fit in very well in this kind of world. If a browser goes directly to a page it can piece together the entire page, but an Ajax request can come in and it can just send back the main content. Very nice.
Just as jQuery kicks off its first jQuery conference adjunct with The Ajax Experience in Boston tomorrow, it gets an energy boost from some big double-barrel news:
Microsoft and jQuery
Microsoft is looking to make jQuery part of their official development platform. Their JavaScript offering today includes the ASP.NET Ajax Framework and they’re looking to expand it with the use of jQuery. This means that jQuery will be distributed with Visual Studio (which will include jQuery intellisense, snippets, examples, and documentation).
Additionally Microsoft will be developing additional controls, or widgets, to run on top of jQuery that will be easily deployable within your .NET applications. jQuery helpers will also be included in the server-side portion of .NET development (in addition to the existing helpers) providing complementary functions to existing ASP.NET AJAX capabilities.
Scott Guthrie talks about the news and details some of the features. His blog shows intellisense at work, and more.
Here is the sample code that shows the weaving of jQuery and Client template APIs. The script src at the top is to an "intellisense" version of jQuery, which includes the addition of special comments to make Intellisense work. The Open Ajax Alliance is trying to standardize on this metadata so we can share it between the various tools (e.g. Aptana has a very nice sdoc that does this, and allows you to put it external to the file so you don't have to have clients download it).
Nokia is looking to use jQuery to develop applications for their WebKit-based Web Run-Time. The run-time is a stripped-down browser rendering engine that allows for easy, but powerful, application development. This means that jQuery will be distributed on all Nokia phones that include the web run-time.
To start Nokia will be moving a number of their applications to work on the run-time (such as Maps) and building them using jQuery. jQuery will become part of their widget development platform, meaning that any developer will be able to use jQuery in the construction of widgets for Nokia phones.
How will these companies work with the project?
Microsoft and Nokia aren’t looking to make any modifications to jQuery (both in the form of code or licensing) - they simply wish to promote its use as-is. They’ve recognized its position as the most popular JavaScript library and wish to see its growth and popularity continue to flourish.
In fact their developers will begin to help contribute back to the jQuery project by proposing patches, submitting test cases, and providing comprehensive testing against their runtimes. As with any contribution that comes in to the jQuery project it’ll be closely analyzed, reviewed, and accepted or rejected, based upon its merits, by the jQuery development team - no free ride will be given.
A significant level of testing will be added to the project in this respect. The jQuery test suite is already integrated into the test suites of Mozilla and Opera and this move will see a significant level of extra testing being done on Internet Explorer and WebKit - above-and-beyond what is already done by the jQuery team.
IE 8 has an onhashchange event, and Ajax history / bookmark management has been a long time problem of choice for developers.
Zach Leatherman has revisited the problem and has another solution that doesn't require setInterval to check on the location.
On initialization, we load an iframe onto the page that is positioned absolutely at -500px,-500px so the user can’t see it. It is a skeleton page that only needs cross browser code to add an “onscroll” event, and to be able to calculate the scrolled position of the iframe itself. For my example, I use jQuery and the dimensions plugin to accomplish this, but it could easily be trimmed down to only the bare essentials (or ported to a different library).
To add an AJAX history entry into the browser’s history under an assigned hash string, we first add a <a name="hashString">hashString</a> to the <body> tag of the iframe. Using css to increase the size of the a tag proportional to the iframe’s height, we can guarantee scrolling will happen.
Then, we change the location.hash of the iframe to point to that <a> tag. This will scroll the iframe to the content, and create a new entry in the browser’s history object.
Inside the iframe, we have our onscroll event that fires when the scrolling in the previous step took place. (Minor IE-related workaround: The browser’s history object is changed, but the hash property doesn’t when attempting to read it later. Instead, we find the <a> that matches up with the scrollY/pageOffsetY property inside of the iframe, and retrieve the matching hash from the <a> tag.)
The solution gives you history management and back button support in one fell swoop, with the side effect of not having bookmarkability (since the iframe is updated).
The window.name transport is a new technique for secure cross-domain browser based data transfer, and can be utilized for creating secure mashups with untrusted sources. window.name is implemented in Dojo in the new dojox.io.windowName module, and it is very easy to make web services available through the window.name protocol. window.name works by loading a cross-domain HTML file in an iframe. The HTML file then sets its window.name to the string content that should be delivered to the requester. The requester can then retrieve the window.name value as the response. The requested resource never has access to the requester’s environment (JavaScript variables, cookies, and DOM).
var deferred = dojox.io.windowName.send("GET", {url:"http://somesite.com/resource"});
deferred.addCallback(function(result){
alert("The request returned " + result);
});
Kris then goes on to show how to use this with Web services and other scenarios, and explains why you may be interested:
This technique has several advantages over other cross-domain transports:
It is secure, JSONP is not. That is, it is as secure as other frame based secure transports like fragment identifier messaging (FIM), and Subspace. (I)Frames also have their own security issues because frames can change other frames locations, but that is quite a different security exploit, and generally far less serious.
It is much faster than FIM, because it doesn’t have to deal with small packet size of a fragment identifier, and it doesn’t have as many “machine gun” sound effects on IE. It is also faster than Subspace. Subspace requires two iframes and two local HTML files to be loaded to do a request. window.name only requires one iframe and one local file.
It is simpler and more secure than Subspace and FIM. FIM is somewhat complicated, and Subspace is very complicated. Subspace also has a number of extra restrictions and setup requirements, like declaring all of the target hosts in advance and having DNS entries for a number of different particular hosts. window.name is very simple and easy to use.
It does not require any plugins (like Flash) or alternate technologies (like Java).
OpenLaszlo is a fascinating project, and got even more interesting when they went meta, and allowed you to general Ajax applications as well as SWF ones. The 4.1 release is a big one, as it brings full parity to the Ajax side of the house:
OpenLaszlo 4.1 is a major release bringing full support for both the DHTML/Ajax and the SWF/Flash platforms. It also includes over 800 bug fixes and a significantly improved documentation suite.
OpenLaszlo 4.1 has been fully-qualified across the following browser/platform combinations: Safari3/OSX, Firefox2/OSX, Internet Explorer 7/WinXP, Firefox 2/WinXP, and Firefox 2/Linux. We have tested the full suite of demos, samplers, and example applications with the requirement that, when possible, DHTML applications behave the same as their SWF counterparts.
OpenLaszlo 4.1 is now the recommended release for all developers on all platforms, and current users of OL 3.x and 4.0 should investigate upgrading to this new release.
Preliminary support for SWF9 is included in this release but has not been enabled in the developer console.
