Hi all, I've started designing a jQuery UI plugin for building complex search queries in a visual fashion, and wanted to see what people though, or if people had any suggestions. Once the plugin is finished, anyone is welcome to use it of course. I also posted this message in the jQuery UI group, but I thought I'd post it here as well for those who aren't members of the UI group.
I. Overview The goal of the plugin is to create a UI component for piecing together complex multi-component search queries and a simple and visual way. The plugin will allow the user to select some set of desired "search criterion," and then when then submit a query when ready (the rest of the logic thereafter is out of the realm of this plugin, and will be handled by the developer). To handle this, the plugin will be broken into three components: Inactive, active, and current search criterion. The inactive and active criterion are lists of criterion (will come back to exactly what these are later) that either have or have not been applied, and the current search criterion is a single criterion currently in "focus." Although the Developer will have control over where these various components sit, one simple setup would be to have a single container split horizontally into the three components: (See Gimp mock-up at http://i61.photobucket.com/albums/h78/hughitt1/uiquerybuilderannotated.png) II. Use case: 1. When the application initially loads, and the inactive search criterion section is populated with a list of criterion the user can use to search by. The current section displays a single search criterion (the most useful one to begin with), possibly with thumbnails for each choice. The inactive section is empty to begin with. 2. The user clicks "option 2" and the filter moves from "current" -> "active" (possibly with some animation), and a new filter from the inactive section moves to "current." 3. User selects again and there are now two "active" search criterion. The current search criterion isn't something the user cares about so they click on one of the other inactive filters and it is swapped with the current one. 4. This process continues until the user is satisfied with the chosen parameters. The "inactive" list may be updated dynamically with new search criterion that are relevant to some criterion already chosen. 5. (Optionally) If the developer has access to a method that returns only the *number* of results for a given query, then this value can be queried each time the user adjusts the query and displayed on screen. 6. The user hits "search" and some function provided by the developer pieces together the active search criterion to produce and query string and sends it off. III. Some useful methods to have: addCriterion removeCriterion activateCriterion deactivateCriterion swapCurrent updateAvailableCriterion updateNumResults submitQuery Event handlers could be available for each action (adding, removing, swapping, etc.) to give the developer further control. IV. How to represent a search criterion? There are many different ways you could handle this. While I would like the keep the plugin very general, and make as few assumptions as possible, I also want the plugin to handle most of the work. So far, what I'm thinking would be best would be to pass around "SearchCriterion" objects which have the following properties: name: int type : string description: string choices: array selected: (int, string, date, etc). priority: int requires: array provides: array I don't know if I will implement all of these, but using this structure will make things pretty straight-forward for the plugin. -"name" would act as both a display name for the search criterion, and possibly also as a unique ID. -"type" would allow specifying what to display when the filter is the current one displayed: text only, thumbnails and text, a datepicker, or a daterange picker. - "description": for tooltips - "choices": available choices to display (special case: dates and date ranges) - "selected": when active, this will hold the value the user selected. - "priority": can be set to give some search criterion priority over others for when to be displayed (0 being the initial criterion to display under "current." - "requires" (optional) Names of other criterion required for this one to be used - "provides" (optional) If present criterion becomes active, add these to the list of inactive. E.g. If the user choses "Automobile", add the search criterion "Number of Wheels." to the list. V. Conclusion There are still some details that need to be hammered out, but this is the idea in a nut-shell. What do people think about it? Any ideas or suggestions? Any feedback would be greatly appreciated. Take care, Keith
