Blog
April 29th, 2008
A common concern of most Ajax applications has been around their resulting accessibility. While, arguably, it's possible to design some form of a usable web page without the use of JavaScript it should be possible - with the additional scripting information - to provide a better experience to users. It's at this point that the ARIA specification comes into play. A large set of interaction is defined within it which is able to help web applications communicate directly to a screen reader in an effective manner.
To get a feel for what this interaction looks like, take the example of ARIA Live Regions (more info). With this functionality it would be possible to keep a live-updated list of users and allow the screen reader to keep up-to-date.
Observe the following ARIA-marked-up HTML:
<b>Active Users:
</b>
<p id="users-desc">A list of the currently-connected users.
</p>
<ol aria-live="polite" aria-relevant="additions removals"
aria-describedby="users-desc" id="users">
<li>John
</li>
<li>Mary
</li>
<li>Ted
</li>
<li>Jane
</li>
</ol>
A couple settings are used to make this piece of HTML particularly interactive to the screen reader (the actual JavaScript that will update this list is left out - but needless to say nothing, in particular, is needed beyond simple DOM insertion and removal).
- aria-live="polite" How polite the live area is (as in, how likely is it to butt in to what the user is currently listening to/interacting with). The default is 'polite' - in that it waits until all forms of user interaction have been completed before describing the updates to the user.
- aria-relevant="additions removals" Only notify the user about new node additions and removals. Since we wish to provide the user with a live list of users we can expect them to be both transitioning online and offline - this will give us the appropriate level of updates to make this possible.
- aria-describedby="users-desc" A pointer to the element that describes the contents of the live area. If the user
wishes to know more about what the contents of the field represent this element can be read to them.
What's most important about all of this, though, is that ARIA isn't just a pipe dream of functionality: It's implemented, today, in Firefox 2 and even more-so in the upcoming Firefox 3.
The Google Reader team recently took advantage of this and added full ARIA support to their application. It's safe to say that Google Reader is not a trivial application by any stretch, allowing this to demonstrate the feasibility of ARIA within large-scale web application projects.
In the course of their implementation they built a tool, AxsJAX, which injects ARIA usability enhancements into many pages using a bookmarklet, greasemonkey, or Fire Vox (a Firefox screenreader). They started by seeding a number of Google applications with this drop-in accessibility support (along with a few others, including the XKCD web comic).
I continue to be impressed with what can be accomplished with ARIA - and seeing the work that Google has been putting forth by implementing this functionality in their applications has been incredibly enlightening and encouraging.
Tags: ajax, javascript, accessibility, mozilla, firefox, aria
11 Comments on 'Ajax Accessibility'
January 26th, 2008
The jobs listed here have been relocated to the new JavaScript Ninja JavaScript Jobs board.
While I'm not, currently, looking for any extra work (a full-time job and writing a book will slow you down a bit) I'm frequently forwarded job openings that I would like to pass on to others.
Generally speaking, these jobs fall into a couple areas: 1) Are JavaScript-related (either jQuery or general Ajax). 2) Are within the New York/New England area or are remote contract jobs. If you have a job posting that you'd like me to relay, feel free to contact me and I'll try to push it on.
jQuery Contract Position
Dave Merwin (dmerwin at orcasinc.com) says that he needs some help with "a small but cool project that I want to do in jQuery." Contact him if you're interested.
Boston Interface Design - JavaScript, jQuery, Python
Mark Soper (mark at alluviallabs.com) says:
Alluvial Labs is building Alluvio, a web application for collaborative investment research. The main need is for someone who knows how to make a professional and usable interface aesthetic. We also have lots of opportunity for the work to evolve into development: javascript/jquery, python, etc.
jQuery Plugin Development
Ryan Graf (ryanjgraf at gmail.com) says that:
I'm looking for an experienced developer with jQuery that can help with some work on a plugin (edit-in-place stuff). We've been working on an existing plugin provided by another contributor and have basically re-written the entire plugin to add a lot of extra functionality. We're now facing some interesting cross browser issues with IE6/Safari that have been difficult to debug.
JavaScript/Ajax Writer
Scott Delap (scott at clientjava.com) says:
InfoQ.com (which I'm the lead RIA/JavaScript editor of) is looking for a couple news writers to cover JavaScript and Ajax (for things like say ... JQuery). We'd want them to cover JavaScript and Ajax in general of course in a not too biased manner. Time commitment starts at around 1 post (30/45 minutes a week) and is paying at a competitive rate per post. Here are a few examples of the types of coverage we shoot for: 1, 2, 3, 4, 5, 6.
NYC - Senior JavaScript Engineer
Brian Vinay (brian.vinay at talentbridge.net) is looking to fill a position with Heavy.com. He provides more details:
Heavy’s engineers develop the next-generation technologies for discovering, delivering, and monetizing premium video for millions of consumers. We’re looking for outstanding front-end engineers who want to define the next generation of user interfaces for internet-based video and advertising.
We are hiring senior JavaScript / HTML / CSS software engineers to write cross-browser code for these web applications, for both internal and external use. We are looking for well-rounded developers who know how to create beautiful, lightning-fast interfaces that work at Internet scale… but who can also develop prototypes quickly. You should have a good understanding of, and practical experience with, creative web design using open standards.
Requirements:
* BS/MS/PhD in Computer Science or equivalent.
* Strong JavaScript skills and object oriented design experience, including working knowledge of jQuery, Prototype, Scriptaculous
* Good artistic taste. You will be relentless about elegant CSS layout, tight JavaScript code, all with strict and clean HTML
* Significant experience implementing user interfaces for consumer web services
* Experience with PHP, MySQL and ActionScript is a plus
* Knowledge of user interface design, XML web services and agile development methodologies desired.
* Ideally, you truly love what you do and have a web site to showcase your favorite work.
Ajax Freelance
Brandon Mullins (brandon at bookmesh.com) is looking for someone to help finish the Ajax of Book Mesh:
All of our AJAX images are designed, and the site is 95% completed. However, we are in need of locating a very talented and responsible AJAX pro to work as a direct consultant and freelancer to the BookMesh team, to begin with immediately fixing the kinks in our AJAX functionality (doesn’t work in IE at all, needs to be centered and tidied-up in Firefox & Safari). This same person will be able to stay on board as a freelancer after this small initial task for any and all client-side scripts that we will need, including various Javascript-based feature implementations.
These initial AJAX needs will not take much time at all (~ 7-10 hours), and there may be lots more work in the coming future for the selected freelancer.
Boston - Web Designer
Aaron White (wyrmwood at gmail.com) is looking for a web designer and includes a full description of the position.
NYC - jQuery Developer
Matthew Greenhouse (mgreenhouse at colspace.com) is looking for "any developers that are familiar with jquery and looking for work, ideally in NYC."
Portsmouth, NH - Web Designer
Jeff Leombruno (leombruno at gmail.com) is looking for:
...a high end developer/scripter type person. If you know anyone who might fit that role and would be interested in working in Portsmouth, NH, please feel free to pass along my email address. We're looking for someone with experience who can jump right into developing complex UI's using xhtml/css/js or flash/actionscript/flex type technologies. We do use jQuery here, of course, as well as YUI for some of our more complex interfaces.
Los Angeles - Senior UI Developer
Danny Archambault (darchambault at concorde-inc.com) is looking to fill a senior UI developer position:
Skills: Ajax CSS Photoshop JSP HTML sony Job description: UI Developer / Specialist: A minimum of 5 years of experience working in a team on a complex-phased new technology medium sized web projects. Responsible for developing the user interface for a complex web application with a lot of data entry screens, workflows, views and reports.
Deliverables will include:
* Low-tech mockups using Photoshop, Illustrator, Excel or Visio
* HTML Prototypes with functioning Javascript and data interactions
* Flex application development to support the back-end development
Seattle - User Experience Developer
David Golightly (davidgo at zillow.com) points to a a job posting at Zillow:
We have an opening in Seattle at Zillow.com for a User Experience Developer, eg. JavaScript + HTML template ownership, that we've been looking to fill for over 6 months with no luck. We've interviewed dozens of candidates, but we can't seem to find people in Seattle who have a JavaScript focus. Considering your large fan base, it would be great if you could put a word in for us, as this would be a golden opportunity for the right kind of person - that is, someone who can play a browser like a violin. While we use YUI here, I have great admiration for the principles of jQuery and would love it if we could find someone with a jQuery background. We've got some large, fun, JavaScript-intensive projects coming up over the next year+, now if only we could find a JS fanatic to build them!
NYC - Senior-level Web Developer
Mauvis Ledford (mauvis atkickapps.com) wrote to mention a job at KickApps:
KickApps the premiere white-label social networking company is looking for a Senior-level Web Developer with a core interest in JavaScript / CSS / HTML. We use jQuery here. Must be able to work or relocate to our Manhattan office. Great pay, generous benefits. See our website for more information.
Let me know if this post is, at all, useful to those reading it. If it's not the case then I probably won't attempt it again, but it is nice to pass these on, at least (especially to those looking or some extra JavaScript or jQuery work).
Tags: jobs, ajax, jquery, javascript
8 Comments on 'JavaScript Jobs'
January 9th, 2008
I've just finished writing up some docs on the new Cross-Site XMLHttpRequest feature in Firefox 3. I was a little worried at first, but it definitely appears to be both easy-to-implement and easy-to-use. Specifically, it's an implementation of the W3C Access Control working draft (which is respected by Firefox's XMLHttpRequest).
If you're interested in giving it a try you should fire up your copy of Firefox 3 and get ready to take it for a spin.
In a nutshell, there are two techniques that you can use to achieve your desired cross-site-request result: Specifying a special Access-Control header for your content or including an access-control processing instruction in your XML.
More information can be found in the documentation but here's a quick peek at what your code might look like:
An HTML document (served via PHP) that specifies an Access-Control header: (Demo - FF3 Only)
<?php
// Change this to allow <yourdomain.com> to make it accessible to your site, or allow <*> for ANYONE to be able to access it.
header('Access-Control: allow <ejohn.org>');
?>
<b>John Resig</b>
An XML document that specifies an access-control processing instruction: (Demo - FF3 Only)
<?xml version="1.0" encoding="UTF-8"?>
<!-- Change this to allow="yourdomain.com" to make it accessible to your site, or allow="*" for ANYONE to be able to access it. -->
<?access-control allow="ejohn.org"?>
<simple><name>John Resig</name></simple>
Now what's especially nice about all this is that you don't have to change a single line of your client-side code to make this work! Take, for example, this page which requests an HTML file from a remote domain - and, specifically, the JavaScript within it:
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://dev.jquery.com/~john/xdomain/test.php", true);
xhr.onreadystatechange = function(){
if ( xhr.readyState == 4 ) {
if ( xhr.status == 200 ) {
document.body.innerHTML = "My Name is: " + xhr.responseText;
} else {
document.body.innerHTML = "ERROR";
}
}
};
xhr.send(null);
This is same-old pure-blood JavaScript/DOM/XMLHttpRequest, as we're use to it. For some limited applications, I think this functionality is already going to be terribly useful - and once wider adoption starts to trickle in we can certainly see a whole range of applications, especially in the area of client-side applications and mashups.
Tags: xmlhttprequest, mozilla, ajax, firefox
27 Comments on 'Cross-Site XMLHttpRequest'
November 29th, 2007
I gave a talk, recently, at @Media Ajax on jQuery (and a similar one at the Ajax Experience in Boston). I covered a broad amount of information (all the way from the absolute basics up to building and using plugins).
» Building Interactive Prototypes with jQuery
Here are the files mentioned in the talk:
I've had a ton of requests for the code to the completed social networking site and you can find that here (and in the above zip): social.php
I plan on turning the Ajax Social Networking Site demo into a screencast at some point, as some tend to find it rather compelling and useful.
Please let me know if you have any questions concerning the talk.
Tags: jquery, ajax, presentations, javascript
14 Comments on 'Building Interactive Prototypes with jQuery'
July 22nd, 2007
I'm about to head out the door to go to two conferences back-to-back. If you're going to be at either one, let me know - and we can meet up!
OSCON
I'm going to be here Monday and Tuesday, for the tutorial days. I'll be wearing a Firefox/Mozilla shirt and will be generally promoting JavaScript and the Open Web.
Incidentally, I'll be attending some pretty-cool tutorials:
It's nice, I'm rather server-side-language agnostic now, so I'm happily checking into lots of programming languages. I'm especially looking forward to the Haskell talk, and the upcoming Real World Haskell.
Ajax Experience '07 West
I'm going to be giving a number of talks on jQuery and JavaScript libraries at the Ajax Experience.
And on Friday I'll be on an Ajax Futures Panel with Bill Scott and Douglas Crockford, which should be good fun.
There's going to be a number of jQuery users, and a few members of the jQuery core team, in attendance so we're going to be having a SF jQuery Meetup. If you're in the area, I hope to be able to meet you there!
Tags: mozilla, oscon, ajaxexp, ajax, javascript, presentation
2 Comments on 'OSCON and Ajax Experience'
February 22nd, 2007
After a recent discussion on the jQuery mailing list where someone wondered if "jQuery was OpenAjax compliant" I decided to fully investigate the OpenAjax Alliance.
In the purest sense, the goal of the initiative is to smooth over the interoperability in between JavaScript code bases. Currently that means:
- Keeping the global namespace clean.
- Making sure libraries don't overwrite each others window.onload events.
- Keeping the global XML namespaces clean.
- Keep any attempts to walk to the DOM from breaking.
This is good. Those are simple tasks that many libraries can easily get behind.
Granted, in jQuery we: Already have all our code in one global namespace, we don't promote the use of window.onload, we don't inject (or require) elements into our own XML namespace, and we don't overwrite any of the browsers default methods. Effectively, jQuery's entire OpenAjax implementation is just to defer the use of (the rarely used) $(window).load(...) to the OpenAjax Hub.
Reality is never as good as it seems, though, as I have some issues with both the alliance and the OpenAjax Hub implementation.
The OpenAjax Alliance is very, very, corporate. The alliance is populated by 66 companies and 2 open source projects (one is an open source project, backed by a non-profit foundation and the other is a by-product of university research).
Ok, that's fine - it's corporations wanting to set some standards. Obviously, however, it should be apparent that a number of, very popular, Open Source Ajax-capable JavaScript libraries should join the alliance, if not, at the very least, be consulted about the proposed specifications.
Let's assume that they simply haven't taken the initiative, as of yet. Ok, that's fine - jQuery would like to join the alliance (to provide our input, hopefully steering them in a positive direction). How would this occur?
I've read through the OpenAjax Alliance Members Agreement [PDF] a number of times now, and even enlisted the help of my, more-legally-inclined, friends but came up short. You're allowed to join if you meet the following criteria:
"Members" means the entities which have signed the Members Agreement and whose membership in the OpenAjax Alliance has been approved in accordance with Section 3.1
(emphasis mine) and some more relevant info:
Membership in the Alliance is intended to be broadly available to all organizations or individuals with a demonstrated interest and commitment to the Purpose, which is the development, enhancement, and promotion of programming technologies and techniques based on HTML-based browsers, Javascript, HTTP, or other specifications to provide robust and effective client Internet interactions, including the publication of Alliance roadmaps, Specifications, testing materials, and sample implementations that can be used to promote OpenAjax programming technologies and techniques.
I understand everything except for the "organizations or individuals" statement. jQuery (and Mochikit, Mootools, Prototype) are all popular JavaScript libraries that have no legal backing (Yahoo UI has Yahoo, Dojo has the Dojo Foundation). Unfortunately, since these JavaScript libraries have no legal backing (as a non-profit corporation, for example) they seem to be out of luck.
For more answers I turned to the OpenAjax member wiki which includes this helpful snippet:
Companies (including non-profit organizations such as open source projects) can join OpenAjax Alliance by following the instructions found on the public web site at: http://www.openajax.org/join.html.
On an exceptional basis, individuals can join OpenAjax Alliance, but only after they have an established track record of involvement and contribution to OpenAjax Alliance efforts and after recommendation by an existing Member. In these exceptional cases, the individual must follow the same procedure as companies (i.e., follow instructions at http://www.openajax.org/join.html). At this point, no individuals have been accepted as Members into OpenAjax Alliance.
There's a couple points about these paragraphs that greatly amuse, and confuse, me. First, that only legal entities (e.g. corporations, non-profit corporations, or individuals) can join the alliance. Second, that all open source projects must be non-profit corporations. Third, that no individuals exist within the alliance (nor do they seem to be particularly enthused by the concept).
All of this really boils down to the fact that if I want jQuery to join the alliance (and I as its representative), the project would have to have some sort of legal backing in order to hold up. I can't sign a document claiming specific ownership rights, or control, over something that doesn't, legally, exist.
This is all (hopefully) an overreaction. But the very fact that no non-legally-backed entities exist in the alliance (and the fact that no good corporation would sign a legal agreement ambiguously defining the status of an "organization") leads me to believe that many of today's poplar JavaScript libraries are intended to be left out of the drafting of the OpenAjax requirements.
The implementation of the OpenAjax Hub (Source) is another issue at play here.
The Hub is meant to be this over-arching library that all other code bases plug into. It is, then, from this library that it delegates out to the necessary resources. Currently the basic implementation is 38.3kB uncompressed and about 7kB compressed.
A big issue that I have with the implementation is that it promotes the use of the window onload event as a means of knowing when the DOM is loaded and ready. A better solution has been available since June 2006. There is no reason to use window.onload to wait to do DOM traversal. (There are good reasons to wait for window.onload - but they mostly have to do with images loading.)
In the case of the Hub they make two critical mistakes: They force libraries to wait to do DOM traversing until after the full page has loaded (a deprecated, slow, and obtrusive technique) and they promote the use of vendor-specific event listeners over defined ones. For example:
var enclosedFunc = function(){ return funcOrName.apply(scope, arguments); };
if(window["attachEvent"]){
window.attachEvent("on"+type, enclosedFunc);
} else if(window["addEventListener"]){
window.addEventListener(type, enclosedFunc, false);
} else if(document["addEventListener"]){
document.addEventListener(type, enclosedFunc, false);
}
A minor point about this piece of code is that it promotes the use of Internet Explorer's attachEvent over the standard addEventListener. Additionally, all event object information is lost in the process (in IE) as the global event object is not passed to the original function. Both of which are frowned upon: The first because it's not forward-looking to the day when browsers will support the W3C (or in Opera's case, enforcing it's use of IE's specific methods), the second because there's a serious loss of event information in the process that is not corrected.
The second, mis-guided, part of the Hub's implementation is that of the "Markup Scanner". The goal of the scanner is to, effectively, parse the document once and notify individual libraries when their corresponding markup appears. (For example, I could request to be notified whenever an element in a specific namespace appears in the document - or when an element with a specific attribute is available.)
Throwing standards to the wind, they struck out and decided to build their own selection standards for matching markup. Not only that, but their implementation is mind-bendingly slow. Here's a small snippet from the scanner code:
var childNode, i = 0, childNodes = node.childNodes;
while(childNode = childNodes[i++]){
if (childNode.nodeType!=1)
continue;
OpenAjax.scanNode(childNode);
}
I fear for the corporation who places this on their site, causing a horrible flash of un-JavaScript-enhanced content combined with a freezing-of-the-browser as the scanner attempts to traverse a 10,000 element page.
There are, at least, three very-fast implementations of JavaScript CSS Selector engines that are each capable of tearing through a document in a matter of milliseconds. I highly recommend that the alliance look to one of them to solve this matter.
What irks me the most about this Markup Scanner, and the whole OpenAjax Hub, is the fact that they're deeming their code to be "the" code to standardize upon. In order for it to be a standard piece of code it must, at the very least, be:
- Free of bugs (and, by extension, easy to maintain).
- Mind-bendingly fast.
- Incredibly small.
Currently, the only requirement that the library meets is that it's comparatively small (compressed). However, that's 7kB of code that does nothing but make your library place nice with other libraries.
In my opinion, the OpenAjax hub could be reduced to a number of simple requirements:
- Use DOM event listeners in your code.
- Use a DOM Ready implementation to avoid using window.onload
- Use simple DOM queries to locate your pieces of markup (getElementsByTagName).
- Never overwrite any global variables.
- Keep your code confined to a single, global, namespace.
This would allow all libraries to live peacefully together, perform very quickly, and not require a single byte of overhead code. (Granted, if all libraries used a single DOM Ready implementation, perhaps that would be more cost-worthy.)
In short: The OpenAjax Alliance needs to seriously consider opening up their process to all Open Source JavaScript Libraries, helping to make their standards more practical and effective. Additionally, the OpenAjax Hub should be severely downsized, and reconsidered, if not removed entirely, as its addition serves little practical benefits (that a set of requirements couldn't solve).
Update: I forgot to mention that a number of JavaScript notables, and jQuery users, have already chimed in on the "jQuery is OpenAjax Compliant" blog post. The post on this blog is a follow-up to that.
Tags: javascript, initiative, specification, openajax, ajax
19 Comments on 'Thoughts on OpenAjax'
October 20th, 2006
I just want to let everyone know that I'm going to be presenting at the Ajax Experience this next week here in Boston. I'm going to be giving two presentations: One on the jQuery JavaScript library and another on JavaScript libraries, in general.
The jQuery presentation is going to be demo-heavy, writing lots of cool utilities from scratch. The JavaScript library presentation is going to be much more talk heavy, really picking apart why you would want to use a JavaScript library, all the way to finding the perfect library for you.
Thankfully, I'm going to be giving the JavaScript library presentation first, on Monday - so you should come to that and hear why you should use a library for development, then come to the jQuery presentation on Tuesday to hear why that library should be jQuery ;-)
In all, it's going to be a great time - there's tons of excellent JavaScript coders coming, and I'm really looking forward to meeting all of them.
Tags: ajax, conference, javascript, jquery
6 Comments on 'Ajax Experience Boston'
August 8th, 2005
I'm looking for a Javascript/Design Guru to help get some applications off the ground.
If you can look at Prototype (http://prototype.conio.net/) and say "That's cool, but I can do better!", or you can scoff at the designs on Stylegala (http://stylegala.com/) and CSS Vault (http://cssvault.com/) - then this job is for you!
Knowledge of the following is a must:
- Advanced Object Oriented Javascript
- Ajax (Asynchronous Javascript and XML)
- XHTML
- Advanced, Modern, Design Capabilities
- Advanced CSS
Big Plus:
- Adobe Illustrator
- Knowledge of Microformats
- Knowldge of Social Networks
If you are primarily Javascript OR Design-Oriented - let me know, as I may still have some work for you.
This job will be on a part-time/contract basis - most likely telecommuting. Pay will determined by your skill level and previous experience.
Apply for this Job Here OR email me.
Tags: illustrator, html, xml, xhtml, design, css, jobs, ajax, javascript, adobe
17 Comments on 'Wanted: Javascript/Design Guru'
·
« Previous entries