Chris-
I looked into OpenSearch some. It seems like a pretty promising
standard. For the plugin I want to be able to leave
it up to the developer exactly how the actual queries are generated.
Ideally, once the plugin is done, it could easily be extended
to handle OpenSearch, or any other type of queries. The important
question to consider initially is what minimum set of meta-data
is sufficient to enable these queries to be built (again, the
developer could extend the "SearchCriterion" objects being passed
around
to include any other data they would like).
Rene-
I'm also worried it could be hard to use once finished.. That's why
I'm trying to take some time now to plan it out carefully
and make it as easy to use as possible.
> How does the UI know what graphics to display for a criterion?
Good point. I had thought of allowing "image" or "thumbnails" as a
"type"
of SearchCriterion (text and date/date-range being the other types).
The thumbnails could
either be stored in a separate array "thumbnails," or possibly a hash
with the name of
the choice pointing to the thumbnail to use for that choice. I know
this is already fairly complex,
but to be able to offer this functionality in an automated way, there
isn't really any way to avoid it.
An instance of a thumbnailed "SearchCriterion" might then look like:
{
name: 'material',
type : 'thumbnails'
description: 'Please select a type of material'
choices: ["wood", "plastic", "metal"],
selected: null,
priority: 1,
requires: null,
provides: [
"wood" -> [SearchCriterion, SearchCriterion],
"plastic" -> [SearchCriterion]
],
thumbnails: [
"wood" -> "tree.gif",
"plastic" -> "bottle.gif",
"metal" -> "steel.gif"
]
}
> How do you plan to communicate a search-query to the server?
This part I would leave completely up to the developer. Basically,
each choice for a given SearchCriterion would be associated
with some value. Once the user hits "search," the developer would have
a list of search keys and values (e.g. "material" -> "wood").
It is then up to them on how to deal with this. They would be allowed
to assign an event handler to the search button of course,
so it could be simply a matter of iterating through the search keys
and values and appending them to a url query string:
http://www.somesite.com/search.php?material=wood&etc....
In my case, I will be generating some XML to send off to the server. I
will leave it completely up the the developer though how the
query itself it formed. The plugin simply helps to get a collection of
keys and values from the user from which that query can easily
be built.
> And what kind of results-display do you propose?
Again this isn't something I plan to handle. Although it certainly
would be possibly to envision a search plugin that not only generates
and
sends off queries, but also displays the results, I plan to focus only
on the query interface end of things. The results interface will be up
to the developer to create.
Thank you both for the feedback and suggestions. Please let me know if
you have any other thought or ideas.
Take care,
Keith
> And what kind of results-display do you propose?
On Jul 18, 3:13 pm, "Rene Veerman" <[EMAIL PROTECTED]> wrote:
> 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/uiquerybuilderannotate...
> > )
>
> > 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
