Feedback for new plugin idea: ui.querybuilder
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. 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:
=======================================================
| (Active Search
Criterion...)
|
|
|
| Active Filter 1 Value
Chosen Remove [X] |
|
|
| Active Filter 2 Value
Chosen Remove [X] |
|
|
|
etc...
|
|
|
|-------------------------------------------------------------------------------------------------------------
| (Current Search
Criterion...)
|
|
|
| Please select a
_____:
|
|
|
| option 1 option
2 option 3 |
|
|
|
[Search!] |
|
|
|-------------------------------------------------------------------------------------------------------------
| (Inactive Search
Criterion...)
|
|
|
| Shape Size Color Price
Date Type |
| Style Material Flavor Age
etc... |
|
|
=======================================================
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