While all Notes developers and many power users know how to create a view with all the data they want spread out across multiple columns, it surprises me how many times I see a database that will have several horizontal screen fulls of data across a dozen or more columns. The intent is usually to cram as much of the document’s data into one view as possible with each column dedicated to a single field. The problem is that, besides just bad UI design, it can become increasingly confusing and frustrating for the user to scroll back and forth in order to compare data. Because the first couple of columns in a view usually display the most important set of data, as soon as it is scrolled off the screen it becomes quite difficult to compare the datasets in a meaningful way.
Lucky for us, Notes allows us to display more than just a single fields worth of data in a single column. You have probably seen this sort of thing before in other databases. We use it in several views in both Logistic and VantagePoint:
The advantage to having all of your data spread across multiple columns is the ability to allow the user to sort the view based on any of those columns of data. Therefore, the trick to doing this in a way that will not hinder the end-user’s ability to sort is to always display the data that will be used to sort in the first line of the row and add the secondary data to the other lines. By doing this, multi-value columns are still sortable based on the first line of data in the row.
For our example, we will use the Profile view in VantagePoint. As you can see from the above screenshot, we have only five columns but are displaying a wealth of data from the profile documents. The first column is a categorized column that displays Enabled or Disabled as appropriate. The second column, Name, displays the name of the profile document as well as the server documents being monitored (the first seven, anyway; more on this later). The Exclusions column shows us all field exclusions, if any. The Alerts column shows us information on how alerting is setup, as well as the Logging column shows us how logging has been setup.
As you can see from the example, most of the secondary data is informative, but not data that users would normally want to use to sort the view. At the same time, we are showing the user nearly every field in the document thus allowing them to compare many different documents on a single screen without the need to open these documents individually.
To begin with, we will need to make a couple modifications to the view properties. As shown below, the modifications are made in the Styles tab of the View Properties window:
- In the Rows section, change the Height to 9 lines. This will give you up to nine lines worth of data to display per column.
- Check the box Shrink Rows To Content. If you do not check this box then each row will always be nine lines in height whether you have nine lines of data or not. By checking this box the row height will dynamically change based on the amount of data displayed in the row.
The next step is to create your columns. Our first column is a simple categorized column that displays Enabled or Disabled depending on the profile document’s status. This is not a multi-value column so we will not go into any more detail about it.
The Name column displays the name of the profile document and a list of the first seven server documents that VantagePoint will be monitoring for field level changes. The reason it only displays the first seven are due to the nine line limit in rows as discussed in the View Properties section above. The name of the profile document will take the first line (unless it is exceptionally long and then it might take more than one line), the second line is the static text “Documents to be monitored:”, and lines 3-9 will be a list of servers.
To accomplish this, first you will need to make a quick modification to the Column Properties in the Info tab as shown below:
Set the Multi-value Separator to New Line. This will not only cause all multi-value fields to display each value on a separate line, but will also allow us to display multiple lines of data from our column value formula (see below) on separate lines.
In order to get the Name column to display the profile name, our static text, and the list of server documents, we have the following value in the Name columns Column Value object:
The first thing you should take note of is the use of a colon instead of semicolon at the end of each line except the last one. The use of the colon essentially creates a multi-value list out of the formula output. Because the column has been configured to separate multi-values with a new line, our formula output will be displayed on individual lines within the row.
We then go about creating the remaining columns in a similar fashion:
The Exclusions, Alerts, and Logging columns get a bit more interesting by using some @If statements to display text dynamically based on field values in the back-end document. For instance, in Alerts we have two @If blocks. The first one will display descriptive text based on whether or not alerts will be sent:
(@If(rbSendAlerts = “0″; “Never send alerts”;
rbSendAlerts = “1″; “When any field changes alert”;
rbSendAlerts = “2″; “When specific fields change alert”;
The second block will then display the mail addresses that alerts will be sent to if alerting is enabled:
(@If(rbSendAlerts = “1″ | rbSendAlerts = “2″;
(“…” + (@Name([Abbreviate];lstSendAlertsTo)));
While these are rather simplistic examples of multi-value columns, it will hopefully give you a better insight into how flexible columns can be and just how much data can be crammed into a single column, for good or bad.
Tip: If you really must have all that data spread out among a dozen or more columns that scroll off the screen, then you might find Chris Blatnick’s Simulating a “Frozen” Column tip very helpful.