Are you familiar with OpenSearch? I bring it up because the OpenSearch has already provided some of the semantics to help generalize the search issue. At some point I had built a client with jquery for opensearch + atom and opensearch-suggest + json, but can't share it because it was part of some work I did for the Library of Congress. If you really want to make a generally useful plugin to address search/query etc, I'd really recommend you look at the opensearch protocol to at least understand what generalizations they've already made.
I'd be happy to provide a sounding board and help 're'-create a jquery opensearch plugin if that's the direction you decide to go in. Thatcher On Fri, Jul 18, 2008 at 11:11 AM, Keith Hughitt <[EMAIL PROTECTED]> wrote: > > 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 > -- Christopher Thatcher
