Design
Implementation of Reference Rows
4/6/2008 - This is an attempt to structure our thinking about Reference Rows into clear subsystems and to provide a framework for designing details such as user interface.
5/1/2008 - screen prototypes created by DQW.
5/11/2008 - Updated with latest feedback.
12/2/2008 - 4.0 design prototype (PDF)
0. What are Reference Rows?
Reference Rows are a way to present a summary of several rows in a chart which refer to the same subject matter, while retaining the original ("source") rows and their backing material.
Reference Rows are created from groupings of source rows that represent original material. The groupings are based on a a common value, such as the Common Drug Name in BizInt Smart Charts for Drug Pipelines, or the Common Family in BizInt Smart Charts for Patents. Only those groupings which bring items referring to the same concept are suitable for creating Reference Rows, so for example a group based on patent numbers or priority documents would make a good candidate, but a grouping based on the assignee would not.
Even if a group contains a single source row, a Reference Row will be created.
Reference Rows created from multiple source rows are a new entity in BizInt Smart Charts. From the user's perspective, the Reference Row is a new row that is automatically created from values in the associated source rows. Cells may contain a reference to the source cell or cell text (if user-edited).
The selection of data from the source rows to fill the Reference Row is an important part of this feature. The rules used to select source cells are described in section 8, below.
Several views of a Reference Row are possible.
One view shows the source rows alone, which is roughly the same as the current software except that the extent of the group is indicated. This view may also include an indication of which data is selected to appear in the Reference Row.
A second view shows the Reference Row only, without the component source rows visible. In this view, additional information is included in the row to attribute the contents to the source data. This view also includes a means to return to any of the source records.
A blended view shows the Reference Row together with the source rows. This particular view is intended to help the user select or review which data should appear in the Reference Row. A unique feature of this view is that the user can choose to have all of the source rows appear on the screen at the same time. In order to do this, the screen height will be evenly divided among the source rows.
1. Creating Reference Rows from a Chart
Reference Rows are created based on groupings of rows. Since there is no concept of a group in BizInt Smart Charts 3.x, we can create the groups and the Reference Rows in a single process.
Note: Since groups may be an independently useful feature, and since we may want to support nested groups, including groups that contain Reference Rows, grouping may be implemented independently of Reference Rows internally. Reference Rows may eventually be a specialization of groupings (a subclass).
The grouping in charts will depend on values in a sorted column. The first version of Reference Rows will be based on Common Family or Common Drug Name. Therefore it makes sense that the operation to create the Reference Rows should be an option to Generating Common Drug Name or Identifying Common Families.
For the first implementation, the column used to generate the Reference Row should be built into the application. Other options, such as the initial view for a Reference Row or the cell selection rules, should be available both as preference and as an option during the creation process.
Because users do sometimes need to edit the values in the common column, we also need a command to Create Reference Rows, which will re-create rows based on the grouping column.
We'll allow users to manually change the grouping via the Rows panel.
Tasks required for initial version: automatic sorting of Common functions; command to create Reference Rows; edit cell creation rules (with apply)
a) Cells in Reference Rows
Our first pass of presenting cells in Reference Rows will show the full contents of a source row cell. The user will be able to edit this text.
Future enhancements may include the ability to synthesize the Reference Row cell from the contents of the source cells. This could involve comparing values and attributing a value that was present in some subset of the rows to those sources. In the Patents product, this could involve creating a family which includes all members from all source rows.
b) Order of source rows in a Reference Row
The order of the source rows within each Reference Row should reflect the default selection rule for cells. This may be a preference based on database, update date, phase, or some other attribute. This would allow exporting only the first backing record to be meaningful.
2. Representing Reference Rows on the Screen
Because Reference Rows represent an object that is different from a source row, a Reference Row needs a distinguishing presentation. Depending on the view, the Reference Row may also need to show the extent of source rows from which it is comprised.
Needs to have a way to access backing records - this might be part of how we make Reference Rows look different. We could present a button that is one record link for each source, although this would not work with a large number of records. Perhaps a glyph that makes it clear that multiple records are back there...
One of the views we discussed was a hybrid view that shows the Reference Row with its constitutent source rows. The affordance to open this view should be part of the visual presentation. A [+] box is a common approach to show that an item is composite, or perhaps an arrow that rotates as the Reference Row expands.
Cells need attribution to the source, whether through a tooltip, footnote, color or something else. Should we offer options? We should choose one style for the initial presentation.
Appearance of Reference Row as Group of Source Rows
This could include shading, heavy rules between groups (possibly containing group identification), curved "brackets" in the row number column.
When a Reference Row is collapsed, it should clearly be visible as a Reference Row, and should have the "Show Backing Records" and "Expand" affordances.
Note that the cells in the Reference Row are editable, just like any other chart cell. Changes to the Reference Row do not affect the source rows.
Ideas updated 4/6/08:
We're picturing a header above the Reference Row in which there is focus. The header would have a tabbed file-folder look (curved edges) and would ride over the bottom of the row above. The header would contain something like this example:
[Expand] sources: PJB . Adis . IDdb (web)
[Expand] would provide a means of expanding the current Reference Row.
The list of sources would be "links" to each of the backing records. The "(web)" text would direct the user to the publisher website.
The source information could include source numbers, colors, or other means of attributing the cell content to the sources. This would be the primary (only?) attribution within the application.
Where source rows have a Database column, a Reference Row will have a Sources column. This column will contain the database name and the accession number for each source record. This Sources column may also have attribution information (color or source number).
Ideas updated 5/12/08 (DQW, with PDF examples):
The following PDF's provide a prototype of how reference rows could appear. RefRow_prototype_Closed.pdf shows a view of only reference rows. RefRow_prototype_Open.pdf shows the reference rows and the backing records.
The "Closed" pdf shows only the reference rows. The Database column in today's charts is replaced by a Source column which allows you to see what records make up a reference row. The Source subtable is designed to:
- show how many records make up the reference row
- show which databases are represented. The sub-row number box is color-coded by database. An abbreviated database name is also part of the record ID in the second sub-column
- show the individual records making up the reference rows. The records are identified in the second sub-column with a database ID + the record number in that database (if available). Clicking on the colored box with the sub-row number will bring up that individual record. This should transfer nicely to HTML.
- links to publisher records could be included in the source subtable as the word "(web)" following the record number.
The Row Status column is designed to show the update status for the backing records in a reference row, without having to expand the reference row.
Note that the user should be allowed to specify the text that they want to appear for each database (or select among publisher name/code, db name/code).
Cell attribution is shown for each cell in the reference row by a colored box (similar in color coding and content to the source subtable) in the lower right of the cell. (Alternative presentations of Cell Attribution are discussed in section 9, below.
Open view: Clicking on the icon under the reference row number will open up the sub-rows for that reference row, as shown in the "Open" pdf. Sub-rows are numbered X.y. Clicking on the sub-row number will bring up that record.
In the Open view, the cell selected for display in the reference row is shaded with the database color-code. To change which cell is displayed in the reference row, I envision the user clicking on the cell attribution area, then selecting a different cell.
3. Representing Reference Rows in Print
Reference Rows in printed output will look just like any other chart row, except that cell contents will be attributed to the source.
Printed charts with Reference Rows may need to contain a key to the source attributions. This could appear on a header page, in the chart header or footer, or elsewhere. If the "Sources" column is present in the chart, the contents of that column could serve as the key.
Record numbering in printed charts will need to reflect the fact that the record is one of N for that row. (Printing option should allow the user to specify whether to print all records corresponding to a row, or just the first.)
We should probably offer an option to print a single Reference Row together with its source rows (the expanded view). If an entire chart is expanded, there should be an option to start each Reference Row on a new page. If an expanded Reference Row (or any group) extends beyond a page, there should be a clear indication that this is a continuation of the group, including the group name.
4. Representing Reference Rows in Exports
Reference Rows in HTML exports require distinguishing presentation, cell attribution, and an affordance to view the backing records. Exports do not require a way to dynamically expand the Reference Row.
Backing records have the same issues with record numbering as identified in the Print section, above.
We may offer the user the option to only export the first (default) backing record for each Reference Row. If all backing records are exported, we may require the Source column as an affordance for accessing the records.
Reliance on graphical elements to distinguish Reference Rows from source rows should be optional. There is a risk of the graphic elements being lost when the file is emailed or moved.
5. Changing Group Membership
Every source row will belong to a Reference Row, even if it is a solitary source row.
Reference Rows will appear as the top level in the Rows panel. The source rows which belong to the Reference Row will be shown as subsidiary (indented) items.
This interface will allow us to move a row from one group to another by dragging the row into another group's extent.
We should probably offer other means for users to edit group membership, perhaps a cut/paste or select/move-to operation. [We should offer analogous means for moving rows in a standard chart]
When the contents of a Reference Row are changed, the software should regenerate any affected Reference Rows. This should be handled both for rows gaining and losing source rows.
Note that changing the members in a Reference Row is similar to updating a chart, and we may want to provide a workflow to allow the user to review the Reference Row representations (i.e. the values selected for the Reference Row) for any rows that were affected by the operation.
A Reference Row from which a source row has been removed may be removed completely if the no more rows remain.
6. Updating Charts Containing Reference Rows
- explain how reference rows are different, express selections
- workflow for reviewing the changes
When a chart containing Reference Rows is updated, the composition of the
7. Internal Representation
From the descriptions above, we will develop our first internal representation of Reference Rows.
The RowList will contain objects of a new class Grouping, as well as class ReferenceRow.
8. Rules for Selecting Cell Values
The cells in a Reference Row are constructed from the corresponding cells in the source row(s). The selection of source data will follow per-column rules. Examples of rules to be supported include:
- user preference of source database
- most recently modified source row
- phase of development
- most items of content (most lines)
Additional ideas for rules which can be added at a later date include:
- based on preferred language
- granted vs application
- preferred authority (e.g. for claims)
A default set of rules will create Reference Rows the first time the feature is used. The user will be able to edit these default rules for subsequent charts.
The user can manually override the selection by choosing a cell from a different source row to be presented in the Reference Row, or the user may edit the contents of the Reference Row.
The user will be able to edit the rules used to select source cells for a chart, and the changes will be visible immediately in the Reference Rows. The user should be asked whether to reset selections which have been manually changed (however user edits will not be changed except by explicit user action).
Several different rules are possible, such as selecting data from a preferred database, selecting the most recent source row, "fill in the blanks", selection based on phase, or blending data from the different cells together.
9. Indicating Cell Attribution
One scheme for indicating the source of cells is described in section 2. This is one possible design. Alternatives are described below.
A) To repeat the attribution scheme in section 2, Reference Row cells would be marked in the lower-right corner with the number of the source row (e.g. "2.1"). The text and/or the background of this text would be shaded in a color that corresponds to the source database. When the Reference Row is open, the source cell would be shaded with the color of the source database.
issues: this scheme has two major problems, since cells that come from the same database won't have similar text markings (only color), and since the color coding of open cells may interfere with change highlighting.
B) Rather than using source row numbers, the attribution text could contain a value based on the source database. One standard encoding should be to assign numbers (or letters) sequentially by user database preference. This will not indicate which source row contributed the record, if there are multiple source rows from the same database, but that information in not likely to be of value to an end user of the information.
In this scheme (and possibly in others) the source cell that contributed to the Reference Row should be shaded or otherwise drawn with an emphasized border. While it would be tempting to shade the cell with the same shading as a Reference Row, this might cause visual confusion in the case of a solitary source row.
When exported or printed, the key to the attribution coding should be part of the data (once per page, or in a DHTML "tooltip")
C) A variation of the above would be to use a user-defined tag for data from each database. For example, data from Adis R&D Insight could be labeled "Adis", "A", "RDI", or the like.
D) Rather than using text, the user should have the option to color code the cells to indicate attribution. This will conflict with change coding.
E) The user should have the option to turn on attribution of user edits.
F) If the same cell value comes from multiple sources, eventually we want to give the user the option to attribute all sources or leave attribution blank.
10. Access to Source Records
The user must be able to access the source records from the Reference Row.
When the Reference Row is Open, the user can access the source record from the individual source rows.
When the Reference Row is Closed, the View Record operation should offer a selection of records. (We may want to offer the first source row by default).
One option is to present the source records for one row in tabs.
Direct access to a particular source record should be possible through the Source column (either by double clicking, right mouse menu, or ?).
We may need to require the Source column in exported charts if the user chooses to export all source records.