jQuery is pure enjoyment: you try something and it works.

But the jQuery API documentation needs improvements on interface and content.

The interface is a bit annoying, because of the drawer metaphore. The user must always open a drawer to see what’s inside and close it again to tidy up.jquery2.png

This problem affects both the description of a function and the alphabetical grouping of all the functions. So each function description is actually hidden inside two drawers, one for the tab of the first letter of the function name, and the other for the fuction itself. A bit more complicated than it should be for browsing an API documentation.

Visual jQuery is a replacement of the official interface and content. It’s based on the drawer metaphore as well, but with a twist. The user, knowing what is looking for, imagines a path of predefined categories, and opens all of their drawers to get there. It’s less weird than it seems from this description, but there is some additional problem.

The header eats up almost an half of the vertical space, and it’s not very useful.visualjquery1.png

Scrolling the page down makes the content disappear under the header.visualjquery2.png

Any drawer appears at the top, so after opening a drawer at the bottom the user must scroll the page up to see its content.visualjquery3.png

Simple Style

I’ve just made yet another replacement of the jQuery API documentation.

It’s based on a two columns layout hosting a list of links on the left and the linked content on the right: basic web metaphore.simple_jquery1.png

It’s still far from completion. This is a partial list of what must be done.

  1. add alphabetical positioning for the links on the left; should be something similar to the original alphabetical tabs, just not tabs: clicking on a letter would cause the left pane to scroll
  2. make the functionality the main concept of the documentation and separate functionalities from functions, each in its own filing card: for example, “$( expr )” has now two different functionalities, so they should be represented by two separate filing cards;
  3. add a unique and persistent ID number to each functionality, so that they can be referenced from inside the documentation, and in the wild by means of a an URL ending with this ID; it would appear where now is a #
  4. check the description of any argument; should be very focused about what the function expects, how it’s related to the functionality
  5. add keywords to highlight documentation wide aspects; it would appear where now is the category; should be a comma separated list, with a fixed precedence
  6. check the description, and edit it thinking about the functionality, being very specific on what gets changed and what is returned
  7. find better and useful examples, always involving a DOM context that can be expressed by HTML markup, both in the Before and After sections.
  8. add a comment to a solution, relating it to “synonyms and antonyms”-like solutions
  9. developed at 1024×768 screen resolution using IE6: check others
  10. template adapted to CSS from one generated by Microsoft Word: refine