An excellent post by Mike Alsup described a plugin development pattern that has served him quite well over time. I have used BlockUI (an Alsup creation) on several projects, and it is readily apparent that Mike knows his stuff. The one thing I have always enjoyed and appreciated most about this particular plugin, however, is the simplicity of the implementation. You could argue that this was a creative decision, having little to do with the actual development. I will not speak for Mike, but for me the degree of simplicity is indeed one of the many creative decisions that I make every time I develop a jQuery plugin.
If you think that the creative process behind a jQuery plugin should receive less attention, let me direct you to the User Interface plugin (jQuery UI). The primary intent is to make available reusable components â€” themed and customizable by designers and developers. Strict attention has been paid to documentation, bug fixes, ease of implementation, source control updates, visual appeal, and usability. These "peripheral" considerations are frequently at the forefront of a developer's mind, and typical suggestions for improvement from a supportive community often focus on this creative substance.
Find your plugin's purpose
Any time I develop a new plugin, I ask myself: What exactly is the purpose of going through the motions? Do I want to give back to the community? Is there a portion of the jQuery core library that I am unable to grasp, and developing a plugin will help me to understand it better? Are there no other plugins like the one I want to create, or that I think do not do the job adequately?
When I first began to design and prototype the Accessible News Slider plugin, my primary concern, over all others, was accessibility. I set some bells and whistles aside and focused primarily on meeting the WCAG 1.0. This creative decision gave the plugin a unique quality, and an unexpected amount of attention. Keep focused on your purpose, and the development process will be less demanding.
Open-source the design
One of the benefits of developing any open-source plugin is witnessing first hand the creativity of the community. However, this can only take place when your plugin is theme friendly. Whenever possible, and even when it seems impossible, purely visual elements should find their way into the CSS and XHTML. Limit the number of images that are appended to the DOM dynamically, so that designers will have an easier time editing the plugin. Alternatively, you can provide plugin options that are related strictly to the look-and-feel. This is an important decision that should be made before programming begins. Otherwise, you can quickly code yourself into a corner, where flexibility is limited because of poorly planned functionality.
The Baskin-Robbins approach
Of course, one disadvantage to providing too many options is that designers have limitless choices. It sounds counterintuitive, but allowing too many options, required or otherwise, can produce a quagmire â€” for you. I call this the Baskin-Robbins approach to plugin development. Offering up too many flavors increases the download size of your plugin and can make bug fixes overwhelming. It is better to start with the essentials. As you release future versions, you can use feature requests to gauge what additional options should be included. Troubleshooting will become easier, and you will have an opportunity to grow a solid plugin, as opposed to introducing a slew of quirks in multiple browsers with the initial build.
A final consideration to make in managing the creative process is how to centralize information related to your plugin. This might not affect the actual creative design of the plugin, but it will certainly have an affect on your creativity. If emails are the only way you take suggestions and log bugs, then you might find yourself exhausted quickly. When you organize, and prioritize, you will have more time to concentrate on design and development.
Even if you have a blog with comments turned on, I would suggest using the jQuery plugins repository. I admit that I have been poor at adopting this practice, but in looking back at previous efforts, I realize that I should have documented all previous plugins through this tool. Here you can view feature requests, bug reports, and efficiently oversee all of your releases. Everything you need to provide a professional plugin to the community is already at your fingertips.