I like the idea for this plugin, but fear it might be hard to use once done.
Searches can be about anything. How does the UI know what graphics to display for a criterion? How do you plan to communicate a search-query to the server? And what kind of results-display do you propose? On Fri, Jul 18, 2008 at 5:11 PM, 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 >
