We realised that we were forcing our users to do a lot of tedious filter configuration that could be done for them most of the time. Making changes to Stadium Designer is a time-consuming exercise, but if we can save time for our users by making it quick and easy to create and maintain pages that contain the good ol’ filter-and-datagrid combination, our time would have been well spent.
Let’s take a step back and think about this. Imagine that you need a page that displays employee information. You would like to be able to see: names, surnames, some form of ID number, birth dates, phone numbers, addresses and a couple of other applicable bits of information. You want a datagrid that looks something like this:
Employee Datagrid |
- I want a filter, and I want to filter by
- ID number,
- Name and
- Surname.
We discussed a couple of ways that we can allow our users to do this. We agreed on one and I went and put together a quick paper prototype.
The idea is this: once I have a datagrid, I should be able to add a new filter to my grid (by either right-clicking on the datagrid or selecting a “New Filter” option on the existing datagrid “Filter” property) and then be allowed to choose which columns I want to filter by. In other words, the steps would be:
STEP 1: Configure a datagrid.
Datagrid configured |
Contextual menu or New Filter... option in dropdown |
Select columns from a checkboxlist |
Filter and datagrid |
The assumptions that we can make, should we go this route, are:
- Datagrid column headers and filter field labels are always the same. E.g. if my datagrid has a column with header “EmployeeID” and I specify it as a column I want to filter by, the filter field created for me will be named and labelled “EmployeeID”. If I edit the column’s header later on, the filter field will be updated:
Synchronisation of field labels and headers - The order in which datagrid headers and filter fields appear, match. E.g. if my datagrid has three columns, headered “EmployeeID”, “FirstName”, “LastName” and “Birthdate” and I specify that I want to filter by employee ID and date of birth, the filter fields will be ordered with “EmployeeID” first and “Birthdate” last. If I edit the order of my columns later on, the filter field order will be updated.
- Filter fields are defaulted to type “TextBoxField”, except if the data comes in Date format, which case we assume that the filter field is of type “DateField”. We will not attempt to figure out when a field is or should be of type “DropDownField”.
- If a filter is dragged right above a datagrid in Stadium Designer, the filter is associated with that datagrid by default and we make it easy to add that grid’s columns as filter fields.
5. If a column of a datagrid is deleted and it was included as a filter field, the filter field is deleted.
6. If a column of a datagrid is hidden and it was included as a filter field, the filter field is hidden.
7. It is still possible for a filter to act on multiple datagrids, but this becomes the “difficult-but-possible” route, because we can safely say that this is an edge case.
We hoped that we would be able to break the feature up into two main parts. During the first iteration, we would only implement the “quick” filter creation route, where a new filter is added by right-clicking on the datagrid or selecting New Filter… from the datagrid Filter property. During the second iteration, we could start making changes to the current Filter Field Editor to allow our users to add and remove filter fields from there:
A new filter Field Editor |
We tested the first part of our idea by making a paper prototype and putting it in front of five of our designers. We quickly ran up against a serious discoverability problem. Our designers have learned to follow a particular procedure when creating filter-and-grid pages: drag a filter onto the page, drag a datagrid onto the page, configure datagrid columns, configure filter fields, reselect the datagrid and then map filter fields to datagrid columns.
This meant that not one of our designers discovered that they could add a filter from their datagrid. Our first round of testing revealed two more important things. The first was this: our designers think of the filter control as an addition to a datagrid, rather than a self-sufficient entity. Two testers wondered out loud why a filter was a separate control at all. (The reason that a filter must be a separate control in Stadium is because, in rare cases, users want to filter two datagrids using the same filter). The second thing we learned from our tests was this: implementing the first part of the design only, without altering the current filter Field Editor, would probably cause a great deal of confusion. If designers didn’t know about the new feature, they could happily follow the current method and configure filter fields that are entirely independent of their datagrid. Once they then reselect the datagrid and start mapping fields, they would be presented with the option to select which datagrid columns they want to filter, which would make all their hard work configuring filter fields superfluous.
Usability Testing – Round Two
We changed our prototype to include the changes to the Field Editor. This time, the designers followed their usual procedure, but when they got to the point where they had to configure the filter fields, they were presented with the option to simply select the columns that they wanted to filter:
New filter Field Editor - nothing checked |
- Field Type (whether the filter field is a DateField, TextBoxField or DropDownField) becomes a property of a filter field that can be changed at any time.
- Field Label is displayed as a non-editable property (determined by the datagrid column header).
- Datafield is displayed as a non-editable filter field property.
New filter Field Editor - Cycle Date checked |