The following applies to the authoring of all software libraries, not just jQuery plug-ins, but I’ve been looking at lots of jQuery UI widgets lately, so….
As the author of a shiny new jQuery plug-in, I’m sure that after all of your hard work, you would be very pleased to have other programmers / web developers actually use your plug-in.
For many of you, that’s just not going to happen. Here’s why:
1. Documentation is not optional. Code samples are really nice to have, but are not a substitute for complete and accurate documentation.
I can’t tell you how many jQuery UI widgets I’ve looked at that have no documentation (“I haven’t had time to write it yet”).
There’s a little thing in the software community known as the “ten minute test“. If I can’t figure out how to use the major features of your library/widget/plugin in ten minutes, I’m not going to spend any more time on it, no matter how “great” it is.
2. For data-bound UI widgets, Ajax support is not optional. Nor is adding / editing / deleting data programmatically after the widget is first rendered.
Transforming html into a data widget (e.g. an html table into a grid) is great for a demo, but most real-world applications will need data from a server.
3. For data-bound UI widgets supporting Ajax, JSON support is not optional.
No – I’m just not going to use XML. Get over it.
4. For data-bound UI widgets supporting Ajax, data samples are not optional.
It’s nice to provide server-side code samples for producing the data that the widget consumes, but they are no substitute for actual examples of the xml and JSON data.
I don’t generally program in PHP, and I’m not going sit and decipher your sample PHP code to try to figure out your data format.
Folks who are contemplating using your plug-in are programmers, and should be able to figure out how to produce the required data format in their chosen server-side language – just tell them what it is.