On 10/28/2011 01:32 PM, Angus Thomas wrote:
There was some discussion earlier around a set of achievable targets
for
functionality behind the UI's global search text field, and around the
filtering controls which are part of the filter table which is used
across the app to present sets of data.
Attempting to get a balance between a design which is sufficiently
simple to implement quickly, and one which is sophisticated enough to be
useful, this is what we came up with:
Also, a couple points which (hopefully) clarify some things.
First, the two items below would be reversed -- i.e. the filtering bits
would be done first, and the Global Search bar last, given the fact that
it may not be strictly necessary for 1.0, and it's a superset of what's
needed for the filtering, as we'll need to take the "within a filter
table" filter bits and add a general non-object-type-specific results
list on top of it. Also, although the global search plan below avoids
needing to integrate a full-text search engine, it still requires
building out most of the UI that we'll use when we do add full-text
search later.
- The global search bar
* Users will only enter a string which they wish to search for, and not
select a set of object types to search across etc.
* There is a finite list of objects in which that text could match (an
instance, an image template, an application template etc.)
* We'll have a single select query for each object which searches for
the user's string in a suitable set of the text fields of each instance
of that object
* We need a new UI page which will represent the query's results, with
some grouping of object types (the running instances grouped, then the
application templates etc.)
* Selecting an entry in the results will open up that instance in the
appropriate details page
- Filtering results in a table
* Users will enter a string into the text box which is in the header of
each instance of the filter table
* The record set contained in the table will be reduced, to only show
those records where the user's text was found amongst the text shown in
the table
While this will mostly be true, the parameters that we choose to include
in the search conditions/filter block aren't strictly based on what
shows up in the table. Rather we'll come up with a limited set of fields
that we expect to search in (name, etc). These will probably be included
in the table, but not every field in the table will be included in the
filtering query. Also, where we pull something into the table that's
nested in an association somewhere (or if it's a calculated field),
these may not be included in what we're including in the filter.
* Note that we're filtering within the record set contained in
the table
- *not* searching for the user's text in additional attributes of the
underlying objects which a row in the table refers to.
* As an additional approach to filtering the records in a table, we'll
add a drop-down list of options to filter on, which will be populated
depending on the object type which is being listed.
This will depend on both object
type and the view that's pulling it --
i.e. the list will be populated in the controller. For example, the
filter options for the regular user list may be different than for those
in the user list on the 'grant permissions' page.
* We'll define a set of options to populate the drop-down list
with for
each object type which is listed in the filter table.
As above, we'll probably
put this in the controller action, since we
will need more than just object type to determine what will show up here.
* For example, when the table contains a list of instances, the
drop-down list will enable filtering based on the state of the instance
i.e. Pending, Running etc.
* The user will be limited to selecting a single entry from the drop
down list to filter the result sets on.
Questions, amendments, etc. gratefully received.
Angus
Scott