Following up the success of the data table to Google chart post, and the request in the comments to do the same for YUI charts, go and check the YUIblog today (like, now) and get your fix there:

• Automatic conversion from simple, accessible data tables to YUI Charts

The elevator pitch:

• Create a valid HTML data table
• Add two script tags to the body and a class to each table
• Have tasty pie charts above each of the tables

[tags]tables,accessibility,yui,flash,progressive enhancement[/tags]

When you write tutorials and you want people to use them wherever they are it is a good idea to offer the HTML documents as a zip for downloading. The benefit to the end user is that they don’t need to be online to look something up (I for example have the HTML 4.01 documents on my machine as HTML documents). The drawback is that the documents could be outdated without the user knowing – even when they are online while watching them.

Now, I pondered a bit about this and wondered if something like this wouldn’t be a solution:

• You add a version number to the title of each document.
• You add a remotely hosted versions.js script at the end of each document.
• This script has a JSON object with the version information of each document and compares the file name and version.
• If the version is outdated, it generates an error message that gets shown to the user.

You can try it out by downloading the two demo documents un-zip them and open them on a computer that is connected to the internet. The second document linked from the first one should be outdated.

The source of versions.js

(checkversion = function(){
// change as fit
var versions = {
'documentexample.html':'1.0',
'documentexample2.html':'2.0'
};
var errorID = 'versionerror';
var errorMessage = 'This document is outdated, please go to the homepage to download the new version!';

// checking code
var d = document;
// get the version number
var cv = d.title.match(/(version (.*))$/);
// get the file name
var cn = window.location.href.split('/');
cn = cn[cn.length-1].split('#')[0];
// check and create error message if there is a mismatch
if(cv[1] && versions[cn]){
if(versions[cn] !== cv[1]){
if(!d.getElementById(errorID)){
var m = d.createElement('div');
m.id = errorID;
m.appendChild(d.createTextNode(errorMessage));
d.body.insertBefore(m,d.body.firstChild);
}
}
}
}());

You could create both the titles and the JSON object in versions.js on the backend automatically by scanning the titles or from a version control system. What do you think?

[tags]offline,HTML,documents,downloadable articles,JavaScript,versioncontrol,webdevtrick,tutorials[/tags]

Google have lately been praised for their chart API and my esteemed colleague Ed Eliot has a workaround for its restrictions in terms of caching and server hits.

I played around a bit with it and thought it very cool but it felt a bit clunky to add all these values to a URL when they could be in the document for those who cannot see pie charts. This is why I wrote a small script that converts data tables to charts using the API and a wee bit of JavaScript.

Using this script you can take a simple, valid and accessible data table like the following and it gets automatically converted to a pie chart.

Browsers

Browser
Percent


Firefox
60
MSIE
25
Opera
10
Safari
5

Simply add the script to the end of the body and it’ll convert all tables with a class called “tochart”. You can define the size (widthxheight) and the colour as a hexadecimal triplet as shown in this example. If you leave size and colour out, the script will use presets you can alter as variables in the script itself.

What about data tables from charts?

As Victor of the Yahoo! Accessibility group asked for the other way around, this is now also possible. When you use the verbose data mode for the charts and add the class “totable” to the image the script will generate a data table preceeding the image and null out the alternative text. For example:

The tables have a class called “generatedfromchart” which you can use to move them off-left if needed.

Check out the demo page and download the script with the demo page and CSS to have a go with it yourself. Of course, all is licensed creative commons, so go nuts.

Useful? Please comment if you want something extra or wonder how the script works.

[tags]accessibility,charts,api,google,tables,javascript[/tags]

Today I will try to find a more accessible way to provide an edit-in-place script. The solution described here is probably not ready for real life yet, please test it in different environments and provide fixes. It is licenced with creative commons share-alike, so go nuts!

I really like the idea of edit-in-place. Probably the most used example of edit-in-place is flickr which allows you to click any heading or description when you are logged in to directly edit it. The reason I like edit-in-place is that it makes it a lot easier for users to describe things, which hopefully results in more accessible and easier to find web sites (after all text is what gets indexed and what is available to everybody). The drawback of edit-in-place is that a lot of solutions are not very accessible. They add a click handler to elements that are not necessarily available to assistive technology and are not at all accessible with a keyboard.

A non-scripting solution attempt

Technically the easiest solution to create an accessible edit-in-place would be to use input fields with labels and use CSS to make them look like the other elements. The code could be the following:

<h1 class="editable">
  <label for="mainheading">Heading:</label>
  <input type="text" id="mainheading" 
         value="Otters in eastern Europe">
</h1>

And the CSS:

.editable label{
  position:absolute;
  top:0;
  left:-9999px;
}
.editable input{
  border:none;
  font-family:arial,sans-serif;
}

But alas! Is it more accessible? I am not sure, as the semantic goodness of a heading is disturbed. I am quite sure search engines will frown upon it and as screen readers work differently in forms mode than in reading mode it might even be more confusing. So let’s scratch that.

Making it work unobtrusively

The next step would be to use a normal heading and somehow connect it with a form field somewhere else in the document. The cool thing about this is that we have something like that in plain HTML: targeted links. For example:

<form id="editform" action="servermagic.php">
<h1 class="editable">
  <a href="#editheader">Edit me, wuss!</a>
</h1>
<p class="editable">
  <a href="#editdescription">Me as well, do it!</a>
</p>
<div id="editingsection">
  <p>
    <label for="editheader">Content of main heading:</label>
    <input type="text" id="editheader" name="editheader">
  </p>
  <p>
    <label for="editdescription">Content of description:</label>
    <input type="text" 
           id="editdescription" 
           name="editdescription">
  </p>
  <p><input type="submit" value="Save Changes"></p>
</div>
</form>

This works without JavaScript (but somehow my Firefox does not highlight the form field when you hit the link, does anyone know why? Please comment!). All it needs to turn it into a working version of edit-in-place is a JavaScript. What the script does is:

• find the section with the ID “editsection” and hide it from view
• find all elements with the class “editable” and add a click handler pointing to an edit function
• override the submit event of the form to point to a store function

The edit function should do the following:

• check if another element is already being edited and focus that if there is one
• Get the ID of the form element from the href of the targeted link
• set the value of the form element to the content of the element
• set an “edited” style to the original element to hide it
• show the form field where the original link was
• focus the form field
• tell the main script what element is currently being edited

The store function should:

• check if there is an element edited (to avoid overriding normal form submission)
• set the content of the targeted link to the value of the field
• move the form field back to where it came from
• set the focus back to the link
• store the content asynchronously (not implemented here)
• stop the normal form submission
• reset the edit state of the script to none

Following is the script that does exactly that. I am using the YUI in this example as I like to concentrate on writing scripts rather than worrying about browser problems. That said, notice that you need to wrap form field focus in a timeout in Firefox, what’s with that?

YAHOO.namespace('ch');
YAHOO.ch.editinplace = function(){
 
  /* Names and IDs used */
  var namesandids = {
    editsection:'editingsection',
    edited:'edited',
    hidden:'hidden',
    editable:'editable',
    form:'editform'
  };
 
  var YE = YAHOO.util.Event,YD = YAHOO.util.Dom;
 
  var edit = {};
  var editingsection = YD.get(namesandids.editsection);
  if(editingsection){
    YD.addClass(editingsection,namesandids.hidden);
 
    function doedit(e){
      if(!edit.target){
        var t = YE.getTarget(e);
        if(t.href){
          var fieldid = t.getAttribute('href').split('#')[1];
          var field = YD.get(fieldid);
          this.appendChild(field);
          field.value = t.innerHTML;
          YD.addClass(t,namesandids.edited);
          setTimeout(function(){field.focus();},10)
          edit = {target:t,field:field,id:fieldid};
        };
      } else {
        setTimeout(function(){edit.field.focus();},10)
      }
      YE.preventDefault(e);
    };
 
    function store(e){
      if(edit.target){
        edit.target.innerHTML = edit.field.value;
        YD.removeClass(edit.target,namesandids.edited);
        editingsection.appendChild(edit.field);
        edit.target.focus();
        // Ajax Magic here, you can used edit.id as the id 
        YE.preventDefault(e);
        edit = {};
      };
    };
 
    var edits = YD.getElementsByClassName(namesandids.editable);
    YE.on(edits,'click',doedit);
    YE.on(YD.get(namesandids.form),'submit',store);
 
  }
}();

Try out the solution and Download the example page with the script as a zip and tell me what you think!

Tested in Firefox, IE7 and Opera 9 on PC, please get me some more feedback on other systems and browsers.

[tags]unobtrusive,accessibility,editinplace,interface[/tags]

I am always fascinated by the amount of Ajax tutorials and examples out there that totally ignore the backend part of an Ajax app. A lot of times you’ll find page-long ravings about the 6-7 lines of JavaScript that allow the client to make an HTTP request but when it comes to talking about the proxy script needed to allow for cross-domain requests a lot is glossed over as “you don’t need to know this, just use this script”.

That would not really be an issue if the scripts offered weren’t that bad. Unsanitized URLs are the main attacking point for cross-server-scripting attacks. If you use a PHP_SELF as the action of your forms you shouldn’t be too confused about a lot of mail traffic from your server or text links on your site you didn’t sign off and get money for.

The other thing about Ajax information on the web that amazes me is that people keep complaining about the slowness and problems with converting data from one format to another on the client side. Let us not kid ourselves: even after all the articles, books and podcasts about Ajax we still have no clue whatsoever what a visitor uses to look at our products. We cannot tell for sure what browser is used, if there is assistive technology involved or anything about the specs of the computer the browser runs on. This to me makes the client side the least preferable place to do heavy calculation and conversion.

The server side, on the other hand, is in your control and you know what it can do. Complex regular expressions, XSLT conversion, all of this is much easier to do on the backend – and you know that the text encoding will work to boot. A lot of complexity of Ajax apps is based on bad architecture and design decisions and on relying on the client side to provide necessary functionality.

So if you ask me what the ratio of client-to-server code of a good Ajax app is I’d say 30% client and 70% server. The 70% on the server should be used to provide security, non-JavaScript fallback functionality (yay accessibility) and conversion of data to small, easy-to-digest chunks for the client (think HTML and JSON). The 30% client side code should mainly be used up to enhance the usability of the product and make it easier for your visitors to reach their goals.

So here’s my plan for 2008: whenever I talk Ajax I will try to cover as much backend as frontend. I’ll do this by partnering with other experts as I myself created some terrible PHP in the past. I hope that others will follow that example as Ajax is a wonderful opportunity to bridge the gap between frontend and backend engineering – and we have to talk to each other to create a good app.

[tags]ajax,development,php,security,xss,architecture,tutorials[/tags]