Thursday 27 October 2011

Adding Filters can be Easy (and when incremental design could result inbewilderment)

Just about every Stadium page contains a filter and a datagrid. This is why we thought it would be a good idea to spend some time thinking about how we could make it easier to set these up. Adding a filter to a datagrid can be a lot easier.

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
You also know that you want to be able to filter by ID, name and surname. To do this, you should be able to tell Stadium four things:
  1. I want a filter, and I want to filter by
  2. ID number,
  3. Name and
  4. Surname.
Stadium should be able to do the rest.

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
STEP 2: Select “New Filter” from a Filter property dropdown or from a contextual menu on the grid.

Contextual menu or New Filter... option in dropdown
STEP 3: Check which columns you want to filter by.

Select columns from a checkboxlist
STEP 4: Hit Save, and there you have your filter.

Filter and datagrid
The filter is configured for you, with some important assumptions made. If you aren’t happy with our assumptions, you are allowed to edit the filter by opening the filter’s Field Editor.

The assumptions that we can make, should we go this route, are:
  1. 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
  2. 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.

  3. 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”.

  4. 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.
In addition:

      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
Usability Testing – Round One

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
When a column header is checked, it becomes selected and the filter field can be edited as usual, with the only differences being that:
  • 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
We have concluded that this feature is the kind of feature that should rather be implemented as a whole, or not at all. Interestingly, an incremental improvement is likely to cause quite a lot of bewilderment.

Upgrade to Framework 4.0

Stadium is currently running on .NET Framework 3.5. We will be upgrading to Framework 4.0 soon.  Some further information regarding this:
  • Why the upgrade?
    .Net Framework 4.0 has a lot of new features and improvements which we will be able to use to improve Stadium. All new framework features are documented at:
    http://msdn.microsoft.com/en-us/library/dd409230(VS.100).aspx

  • Will existing Stadium applications require any changes to work on the new version of the framework?
    Stadium application files i.e. sap files will require no changes. It will work as is on the new version of the framework.

  • What are the system requirements for Framework 4.0?System requirements, download and instructions can be found at:
    http://www.microsoft.com/download/en/details.aspx?id=17718
Any other questions?

Friday 21 October 2011

Feature peek - Test query

As a designer of Stadium,  it would be great if SQL queries used for controls e.g. SelectQuery of DataGrid could be tested within the designer environment so that he/she can be sure that the query is correct and also displays the expected data.  We are introducing the 'Test query' feature in the designer for this purpose.  This will also speed up implementation time as designers are currently using database tools or uploading the sap file and viewing it on Stadium's website to confirm query is correct, this additional step won't be necessary.

A test section will be added to current 'Command Editor' dialog. It will have two tabs: Test Inputs, Test Results as indicated in below screenshot.



  

The 'Test Inputs' tab will be pre-populated with parameters as and when parameters are added, see below wireframe.


User can specify test values in and click on 'Test' button. Results of query will be displayed in 'Test Results' tab as shown below:


Please note these wireframes are rough and gives a an idea of current thoughts and may change when implemented. Thanks to Carien for designing and wireframing the screens for us.

Feedback and comments will be much appreciated.

Wednesday 12 October 2011

Stadium3 Release : 3.2.1917.4213

Build 3.2.1917.4213 is available for download. It includes:
  • Fix for dependant dropdown values not remembered when 'SaveFilterStateOnApplyButtonClick' property is set to True
  • Fix for RefreshParameters button not working on command editor for Text property of label
  • Fix for RDLViewer control not working with date parameters
  • Fix for issue when RefreshControls action was used to set Panel to visible
  • Fix for index out of bounds array when expanding childgrid
  • Panel - Fix for issue with wrapping of text when it is collapsed
  • User will now be locked out after three failed log in attempts
  • Applications displayed in 'Select an application' list can now be ordered
  • All folders are now collapsed by default in designer
  • Folders can be moved in designer
  • RefreshControls action now includes treeview control
  • Designers can now find all occurrences of user controls, connections, custom settings, validations, access rights, pages, access rights, master pages in designer
  • Filter - 'Include' checkboxes cell is checked automatically when user types in filter value
  • Filter - TextBox fields now have 'Like' as default condition in designer
  • TreeView - Node has new ColourField property
  • TreeView - New path control property
  • New ExportToExcel action
  • DataGrid - New sql query source for link column
  • ChildGrid - New LeftMargin property
  • Creating a new application in designer creates a new page and master page automatically
  • Finally it is now possible to refresh an application via Admin->Manage Applications page,  designers don't have to upload the changed sap files.
Note: It is likely after you upgrade and open the designer, the various panels: Application explorer, user controls, events are located at incorrect positions. The StadiumDesigner.Docking.config file contains the panel location settings for each user. This file will have to be deleted for the panels to be reset to original locations.

This config file can be found in the user's roaming application data folder for Stadium. This is typically located in the following directory:

Windows 7 & Windows Vista:
C:\Users\<UserName>\AppData\Roaming\Twenty57\Stadium

Windows XP:
C:\Documents and Settings\<UserName>\Application Data\Twenty57\Stadium