IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

The option "Categorized as flat version 5 or greater" is one of life's little mysteries. What exactly does this do? The Designer help says:

If your view is [categorized], you can select "Categorized is flat version 5 or greater" to convert your view to a non-hierarchical, flat view, which displays all documents on a single level. Use this feature if your level of indentation in a view exceeds the limit of 32 levels.

Now, to me, this seems to be saying that if you use this option, the view is actually not categorized.  But in that case, why bother to add an option, since you could already do that by selecting sort rather than categorize to each column. There must be more to it than that. So I decided to try it. I started by creating a view with three categorized columns:


original view

Then I experimented with turning on the "categorized as flat" option for various combinations of columns:


column 1 flat

Columns 1 and 2 have essentially been combined into a single category -- one twistie displays all documents with the same requestor and status.

One thing I notice right away is that the value of column 1 is also displayed on the document row entries, which seems useless to me since all the documents in that category will have the same value there. Unless someone likes that behavior and can give a reason why, I plan to write an bug report.


columns 1 and 2 flat

All categorized columns are combined so that they effectively function as a single category. It's as if you created one column with the formula Requester+Status+AssignedTo and categorized that, except that they appear as three separate columns and let you control their widths and fonts separately.

Of course, having a twistie on each column is unnecessary; they all do the same thing.


columns 1, 2 and 3 flat

Now the view is simply sorted, as the documentation suggested.


column 3 flat

Notes forgets that the column is categorized, and only sorts it.


column 2 flat

Columns 2 and 3 are combined for sorting purposes.


column 2 flat, but column 2 is set to sort "None"

Even if you turn off sorting for column 2, if you make it "categorized as flat," it's used as part of the category heading with the next column which is categorized.


column 2 flat, where column 3 is categorized descending

To sum up what we're seeing here, "categorized as flat" apparently merges that column with the next column for sorting/categorization purposes, but maintaining the sort direction of each column (where "none" apparently defaults to "ascending"). This lets you reduce the depth of your category tree.

Aside from avoiding Notes' limit on categorization depth as the doc suggests, this also lets users navigate to document rows with fewer clicks. In any case where the number of combinations of two categorized columns will be small, you can consider the tradeoff of the user's time in scanning a longer list of the category headings for the combination they want, versus the number of times they need to expand a category to find a desired document.

For instance: If column 2 can contain two values, and column 3 can contain two values, and they're individually categorized, then the user has to decide between 2 values, click, decide between 2 more values, and click again -- a total of 4 values to examine, and two clicks. If you set column 2 to "categorized as flat", there are 2*2 4 combinations, but only one click to make the document visible -- "categorized as flat" saves a click, without any additional eyeball labor.

Or, say column 2 has three possible values, and column 3 has three. If separately categorized, there are 3 + 3 = 6 values to examine, and two clicks. If column 2 is "flat", there are 3 * 3 = 9 value combinations, but one click. One could argue that saving the user a click is worth giving them 3 more choices to look through.

Or, if there are a dozen choices each, the comparison is 12+12 = 24 values one way, with two clicks, vs. 12*12 = 144 choices the other way, with one click. This sounds like the "flat" option will be more trouble for the user.

You must also consider not only what the maximum number of value combinations will be, but the probable number of those combinations that will have at least one document in them. That depends on your data and the statistical distribution of your values. If you already have data in the application, it might be easiest to do this empirically with a document-scanning script, rather than try to calculate it (but bearing in mind that you'll probably add documents as time goes on).

Of course, that business of displaying the "flat" column on all the rows is kind of annoying, and the clutter/user confusion factor might prevent you from using this feature even when the numbers would seem to call for it. But anyway, that's what it does and that's my take on it. Hope this is useful.

I didn't try what would happen when this option is used with column values that contain \ (a.k.a. "ad hoc subcategorization"). If anyone feels like pitching in, that might be something to try.

Andre Guirard | 16 July 2009 08:00:00 AM ET | | Comments (8)

Search this blog 

Disclaimer 

    About IBM Privacy Contact