On Fri, Oct 28, 2011 at 06:32:31PM +0100, Angus Thomas wrote:
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:
Thanks for writing this up and sending it out!
* 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.)
Ken may already have something fantastic here, but I don't think it
needs to be anything other than, for each object type, printing an H1
header and then showing the typical filter_table view for that object.
Quick to implement, and it's a UI the user is familiar with. I will, of
course, merrily defer to Ken's suggestion if he has something different.
- 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
* 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.
Another way of stating that last point is that we will only search on
the fields a user sees. This simplifies the search a bit, and avoids
giving users baffling results.
* 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.
* 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.
* 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.
I'd advocate keeping this simple -- have a couple common-sense filters,
but don't go overboard with them.